Refactor unit tests to not use Ginkgo

[anik120]

Learned that @joelanford and @ncdc are of the opinion that using ginkgo for unit tests is introducing unnecessary complexity, which @stevekuznetsov has alluded to here too.

[ncdc]

Using ginkgo for anything introduces too much complexity 😄

[ncdc]

At least, it does for me. I have always struggled to understand when to use BeforeEach, JustBeforeEach, Describe, When, It, etc. Maybe if everyone is an expert in it, it provides a lot of value, but when you're not, it's super confusing. I prefer plain go tests, table driven when it makes sense, with testify and cmp.Diff.

[stevekuznetsov]

I think many, many years have passed since there was a compelling technical reason to use Ginkgo. In the very early days, sub-tests did not exist and parallelism was harder to mange in Go standard library testing, so Ginkgo had some advantages. Today, not so much.

If you prefer BDD-style assertions, the testify package Andy mentions gets you everything you need without adding on a bunch of onerous expectations like Gomega does, or inflating the number of ways to do something - Gomega suffers from a lot of cases where thirteen different assertions are almost entirely identical, except for that one case, blah blah.

cmp.Diff() is a great option for test assertions since it pushes you to do a couple things:

1. compare static structures, which means your tests use local object literals or golden files, which are easy to inspect and not interrelated between cases
2. only compare public members of objects by default
3. explicitly write comparators for cases where you want specific behavior