I’m still – still – playing with Google’s Go language, making the occasional one-off utility and also working on a Crazy Web Server Project. I hesitate to call it a Framework, since all Frameworks are ultimately doomed. It’s nothing too extreme, but it’s (hopefully) going to solve some of my web-server problems for small sites; and it’s (absolutely) helping me learn Go “for reals.”
I recently discovered something very simple, more or less by accident, that has big implications. It is this: tests for package foo should declare package foo_test.
To me this was counterintuitive, since one of the big hairy things you have to adjust to when learning go is the flat package directory. A package is made up of a bunch of .go files, and they all live in one flat directory. If you want to organize the files in a hierarchical set of directories, you must also have a corresponding set of packages (though they need not be hierarchical).
Incidentally, as I get better at Go I find myself hating such conventions less, because they are useful in forcing the programmer’s hand: be idiomatic damn you! And that certainly has its upsides.
Thus, logically, every .go file in a given directory declares the same package. If it doesn’t, you get a compile-time error!
Except, that is, for tests.
The Test Exception
For a directory with a package foo, you may have two packages: foo and foo_test. You may not have any others. So, why would you want to use foo_test?
There is a very good reason, which I’ll get to in a moment. If you already have a lot of unit-testing experience and know a little Go you may already have guessed.
Let’s first consider the way I had been doing it until recently. Apologies in advance for the lack of syntax highlighting.
foo.go
package foo
func Bar() string { return "BAZ"}
foo_test.go
package foo
import "testing"
func Test_Bar(t *testing.T) {
exp := "BAZ"
got := Bar()
if got != exp {
t.Errorf("Expected '%s', got '%s'", exp, got)
}
}
OK, great. This makes perfect sense so far. But now consider this, which in fact seems quite the obvious thing to do:
foo.go
package foo
func Bar() string { return ook(1) }
func ook(i int) string {
if i > 0 {
return "BAZ"
} else {
return "BAT"
}
}
foo_test.go
package foo
import "testing"
func Test_Bar(t *testing.T) {
exp := "BAZ"
got := Bar()
if got != exp {
t.Errorf("Expected '%s', got '%s'", exp, got)
}
}
func Test_ook(t *testing.T) {
exp0 := "BAT"
got0 := ook(0)
if got0 != exp0 {
t.Errorf("For 0, expected '%s', got '%s'", exp0, got0)
}
exp1 := "BAZ"
got1 := ook(1)
if got1 != exp1 {
t.Errorf("For 1, expected '%s', got '%s'", exp1, got1)
}
}
The example above shows a very common pattern, about whose virtue we could certainly argue: you can have much more thorough test coverage if you have robust unit tests for private functions. (Remember, in Go only Capitalized functions are exported.)
However, there’s a cost in clarity: you should be testing all things that could happen in the use of the package, i.e. you should be testing all variations of the public API. If there are conditions your public API can not trigger, and which thus can not be tested via the public API, then remove them from the code.
Go is strongly biased towards writing only the code that is actually used. Speculative code, while possible, is definitely not idiomatic.
As somebody who writes code for a lot of “what-if” scenarios in Perl, I can certainly apprecitate that discipline.
This is why you should use the foo_test package: Go will then throw a compile time error if you try to test a private function, and in your quest for 100% code coverage you will see the unreachable parts of your code.
So let’s get back to our example, changing the test first:
foo_test.go
package foo_test
import (
"./"
"testing"
)
func Test_Bar(t *testing.T) {
exp := "BAZ"
got := foo.Bar()
if got != exp {
t.Errorf("Expected '%s', got '%s'", exp, got)
}
}
If Bar is the only thing that ever calls ook then you’ll have to change ook or you’ll never get 100% coverage. In this contrived example, the compiler will most likely abstract away ook entirely, but bear with me.
foo.go
package foo
func Bar() string { return ook() }
func ook() string {
return "BAZ"
}
And there we have it, in silly little examples. Always use a _test package name for your Go tests. Testing will be harder. Deal with it: your tests will also be better.
