Problem: We’re working in a Go monorepo. I’ve been writing tests for one package in one service in said monorepo. When I run
godep go test ./directoryofinterest,
I get the following (positive) message:
ok github.com/path/to/my/directoryofinterest 0.019s.
When I run
godep go test ./directoryofinterest -v,
I get several failure messages in the main part of the output, and the last two lines are
ok github.com/path/to/my/directoryofinterest 0.021.
This is definitely some unexpected behavior.
Working through some of the 11th chapter of The Go Programming Language has surfaced a few idiosyncrasies.
go test from the directory where the tests are returns 2 lines, whereas running
go test ./directoryofinterest from one directory up returns only one line.
When you get the 2 lines, one is a
FAIL message, and the second is the
Fun fact: it’s because i”m using an old version of Data Dog’s sqlmock.
After updating sqlmock to the current version, I get the expected behavior when running the tests.
go test ./directoryofinterest now returns 1 line when tests pass with the ‘ok’ message. Running the same command with failing tests returns multiple lines with the details of the failure, and the final line contains the FAIL message.
Why aren’t my test running?
go test will only pick up tests in the directory that the command is being run in. To have it find tests in sub-folders, try the command
go test ./.... This searches recursively through the sub-folders and finds the hiding tests and runs them.
Tests still aren’t running? If you are using godep to manage dependancies, you can try:
Still getting error messages á la:
somefolder/some_test.go:10:2: cannot find package "github.com/THING/code" in any of:
/usr/local/Cellar/go/1.5.1/libexec/src/github.com/THING/code (from $GOROOT)
~/code/go/src/github.com/THING/code (from $GOPATH)
Try the following series of commands from the root directory of your project.
rm -rf Godeps
godep save ./...
godep go test ./...
go test ./...
Stay tuned for an actual explanation of why any of this works when I figure it out!
When writing tests in Go, there are a few useful ways to get info printed out to the screen.
Inside the test, you can log stuff using
t.log. This will only show up if you use the
-v flag when running
Inside the actual program itself, you can print things using an
fmt.Print command, and running the tests with the
-v flag is your friend when you want to see things in your go tests!
- When a test is especially short or simple compared to the application code it tests, lean toward writing the test first.
- When the desired behavior isn’t yet crystal clear, lean toward writing the application code first, then write a test to codify the result.
- Because security is a top priority, err on the side of writing tests of the security model first.
- Whenever a bug is found, write a test to reproduce it and protect against regressions, then write the application code to fix it.
- Lean against writing tests for code (such as detailed HTML structure) likely to change in the future.
- Write tests before refactoring code, focusing on testing error-prone code that’s especially likely to break.
— Michael Hartl, Ruby on Rails Tutorial