datadriven VS rapid

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

You can check the package here, in official GitHub repo. I recently found this amazing testing framework and now I can't imagine developing tests without it. Let's try to refactor our previous example with this package:

Yes, but using quick is just a PITA, I'd recommend using Rapid https://github.com/flyingmutant/rapid instead

For finite solutions that you can fit in your head maybe, but I'm still sure that fuzzing, coverage, and [advanced testing](https://github.com/flyingmutant/rapid) are ways to go. And nothing beats integration testing if you need to see how application interacts as a whole.