datadriven VS testy

Table driven tests are a lot better than a bunch of imperative tests but they rapidly become unwieldy to debug, maintain, and evolve. Their readability often isn’t great.

If you’re using go, check out https://github.com/cockroachdb/datadriven. It takes a little bit of effort to craft a testing dsl, but it is so worth it.

Also, snapshot style testing where the test writes out its expectations and you just inspect it and save it (part of datadriven) is wonderful.

I’ve been using insta in rust lately and it’s some of what I want but not quite datadriven.

I’ve found the datadriven[1] testing approach in go to be quite effective. The idea is that you leverage a standardized file structure to construct a little DSL for testing your code. This allows you to write expressive tests that print the state of the code and then look at it. Rewrite is also very powerful.

This is all inspired by the sqllite logic test framework.

[1]: https://github.com/cockroachdb/datadriven

Agreed with most of this but I’m skeptical of the rsc.io/script dsl approach. I’ll try it, though, because Russ is often right.

shameless advert: do you wish testify was implemented with generics and go-cmp, and had a more understandable surface area? Check out my small zero-dep library, Testy https://github.com/peterldowns/testy

shameless advert: do you want to write tests against your postgres database, but each new test adds seconds to your test suite? Check out pgtestdb, the marginal cost of each test is measured in tens of milliseconds, and each test gets a unique and isolated postgres instance — with all your migrations applied. https://github.com/peterldowns/pgtestdb

Finished, take a look if you're curious --

https://github.com/peterldowns/testy