Ginkgo and Gomega: BDD-Style testing in Go
Why you should use Go
Go is an open source platform as a service and is much faster than languages like Ruby and provides easy methods for moving your Command Line Interface from Ruby to Go. Ruby, however, has a much larger developer ecosystem with Rails giving so much away for free for Ruby. In Go, the largest problem is how to test in the new ecosystem.
Software is often written to satisfy a specification. This is a static idea isolated from the code and makes it hard to verify the specifics and test the code for errors. To do so you need to take code and write unit tests and then wrap them with integration tests. Writing dynamic tests integrated with the code allows you to have repeatable verifiability and guarantees that your code will work as you refactor, add new features, and as you change components.
At Pivotal Labs, test driven development comprised of tests, red, code, refactor, repeat takes the front stage. This is because through the discipline of first running tests, then code covers all the bases and guarantees that there is a test for everything. This pushes forward that tests are communication and that pairing programming and better documentation with consistent testing creates better code than just comments. This pushes the idea that better code is better because it has to be testable compared to untestable code that collapses into a "big pile of spaghetti" when it fails.
Testing in Go
The first myth is that testing is unnecessary in a compiled statistically typed language. This is false. A compiled language can make guarantees about interfaces and types but not about the behavior of an object let alone objects inside. Testing in Go is considered a first-class citizen, in fact it's as easy as import, write and run tests. This is done through xUnit style tests with no matcher/assertion library. The reason is because it is easy to write unit tests that lack features such as assertion functions and that testing frameworks tend to develop into mini-languages of their own.
Using the base testing in Go is hard using the included methods because the documentation is unclear, there's lots of repeated setup and lots of repeated custom error handling. Making it into one large test doesn't help, as does making it a table driven test because neither is clearer. This leads to the tests having 1.5 to three times as much code as the actual code.
By using Ginkgo and Gomega you get access to BDD-style testing for Go. Ginkgo is the testing framework with Gomega acting as the matcher library. These are both available through github in Go and give rich semantics for describing your code's behavior. The shared test setup and teardown, short descriptive isolated tests and nested contexts make testing code branches natural while the tests themselves act as specification and documentation. The BDD-style promotes effective pairing and test coverage and while young, Ginkgo acts very mature for a testing platorm.
Gomega allows for and prefers one-line assertions and provides consistent descriptive output for free. With a rich library of matchers and the ease of writing custom matchers Gomega allows you to expressively describe the behavior of your domain.