smarty/gunit vs. mdwhatcott/testing/should

Introduction

I've written several test libraries for the Go programming language. My best 2 so far are quite similar, but differ as follows.

TL;DR

• old: github.com/smartystreets/gunit
• new: github.com/mdwhatcott/testing/should

You should use the new one. It's more flexible and facilitates more scenarios (with a lot less code).

Similarities

• Both are loose implementations of xUnit-style test fixtures.
• Both have a rich set of should-style assertions.
• Both integrate with the Go testing package in basically the same manner.
• Both are excellent.

Virtues of github.com/smartystreets/gunit

• Battle-hardened, has tested hundreds of thousands, maybe millions of lines of code since 2015 (but the assertions package has been around since 2013).
• The assertions package (github.com/smartystreets/assertions) has a TON of assertions.
• Runs test cases as sub-tests, in parallel, or sequentially

Limitations of github.com/smartystreets/gunit

• The gunit code that runs the fixtures is a little too factored out and is somewhat hard to follow.
• The assertions package leverages a few external ('vendored') dependencies for some of the low-level heavy lifting. (I was less experienced w/ Go at the time and wasn't excited about implementing should.Equal on my own.) This external code weighs in a several thousand lines.
• gunit is meant for unit testing. You can do integration testing with it, but it has limitations, such as a lack of once-per-fixture setup/teardown functions/methods.
• should.Equal vs. should.Resemble is confusing and, in retrospect, unnecessary. UPDATE (2023-07): should.Equal and should.Resemble are now equal in behavior so this is no longer a valid limitation.

Virtues of github.com/mdwhatcott/testing/should

• All the code for both the test runner and the assertions is contained in a single package and is much smaller. (10,000 lines vs. 2,800 lines)
• All code is my own, no 'vendored' dependencies.
• Negated assertions have their own namespace for easy discovery (should.NOT.Equal vs. should.NotEqual).
• should.Equal handles structs, slices, arrays, and maps, etc..
• better support for integration tests (once-per-fixture setup/teardown funcs).

Limitations of github.com/mdwhatcott/testing/should

• Some assertions missing (but would be trivial to implement)
• Stack traces and diff reporting are more simple (maybe not always better)