- Why Go avoids assert libraries
- Better alternatives to mocks
- Make writing tests fun!
Today’s post is a taste of what we’ll cover.
Pop quiz. Does this testify assertion pass or fail?
var x []int
y := []int{}
require.Equal(t, x, y)
If you’re like me, you have no idea. Arguments for both seem reasonable. And the docs don’t help.
Is the learning curve worth it?
Assertion libraries are popular in Go, and for a solid reason: they make tests shorter. But in exchange, you’re signing up for some hefty costs, which are often overlooked. A few, from the official Go wiki:
- They require developers to learn a whole new sub-language just to read or write tests
- Most assertions abort a test early, omitting potentially useful information from the output
- They hurt expressiveness, both in communicating what is being asserted, and in how you present failures
- They make it easy to write imprecise tests
- They duplicate features already found in the language, such as evaluation, comparison, and often more
And a few more reasons of my own:
- Many assertion libraries are internally inconsistent (
testifyis one such example) - They require a combinatoric explosion of functions to express slight variants on certain checks, which are much easier expressed using first-class language features such as
!or&&
