Yeah, I think integration tests definitely give you a more real-world kind of test. Actually, one thing I will say I do a lot more recently is more kind of a quick-check test. There was testing/quick in the standard library. So – quick-check tests, you know what they are. It’s just basically randomized testing. And there’s really fancy quick-check stuff in other languages, but on Go you’re basically just handing that off a rant, like a math rant to a test, and then generating tests from that. I find that to be one of the best ways, especially for libraries, where they’re more self-contained, to actually go through all kinds of different iterations you wouldn’t expect.
I had an implementation of immutable sets, immutable collections, where I’d actually make a – I had the immutable collection, which… So immutable collections, if you don’t know what they are, is whenever you make a change to the collection, you make a new copy of that collection. And it doesn’t make a whole giant copy, it just gives you a new copy with a little bit of a change.
So I did the tests… It was a quick-check kind of test, where I would basically randomly insert/delete/change around the collection, but I’d also do it on another kind of just in-memory basic collection. It was very inefficient, the in-memory one, but I knew that it would work… Just like a Go map, basically. So then I could test that both implementations did the same thing, with random different inputs. I find that to be super-helpful.