iParadigms/walker — pull request #69 by pchristopher1275 (2014-11-06 19:10:18+00:00)
Title: Util prog

Hey Guys,

This patch solves the testing woes by building some infrastructure that
makes it easy to script commands together, and adding a testing job. But
looking at what I have, I'm not sure it's the thing y'all will want. I want to
articulate the reasons that brought us to util/main.go. And then I want to discuss
some of my design decisions. It seems like this pull request may server as our
ongoing discussion about testing...

There are several bullets to consider on our testing history:

(*) We have fairly long test invocations: for example

sudo -E go test -tags "sudo cassandra" github.com/iParadigms/walker/test
-cover -coverpkg github.com/iParadigms/walker

(*) We have a separate script that produces line-by-line coverage results, vs.
aggregate results -- which are separately maintained.

This is script/test.sh vs script/coverage.sh

(*) To merge test.sh and coverage.sh would have meant writing a fair bit of shell
script.

(*) But at the same time, we've had a couple issues where something was
correct in one script, but not the other, and vice versa. For example one
script had -tags incorrectly specified which made the developer think that
tests where all passing, when they weren't being run.

(*) The above two points would imply that we should merge the code into a single
shell script, but that script would be fairly voluminous and we'd have to support
a bash script moving forward.

(*) How do we run a single test? Here is how I do it for the most common tests
[here I'm sitting in the walker directory]

(cd test && sudo -E go test -v -run NameOfFunctionToRun fetcher_test.go)

At times in the past, I would sometimes have to add files to the invocation to make it work, so
something like

(cd test && sudo -E go test -v -run NameOfFunctionToRun fetcher_test.go helpers.go mocks.go)

[in the fetcher_test case this has been changed so it's not needed. But any time a test uses something in
the test package, from a different file, that file will need to be included ]. Are there better ways
to do this? If we stuck with a util/main.go way, it would be easy to shrink the user interface.

----

Some design decisions for util/main.go

(*) I would expect util/main.go to seat several developer tools: testing, and db
conditioning for example. This basically becomes a place to put tasks similar
to the C++ librarys rake task

(*) It would be easy to extend the logic of these tools using go, rather than
having a set of scripts laying around.

(*) Because I included the shell expansion stuff, and because a developer looks at a
complete command line, rather than a list of string, it meant we can pull a
command line from our manual use-case, and stick it into the program with
minimal fuss. Makes it easier to script commands together.