I had a great experience introducing the rapid library for stateful property testing at work. We’re a Golang shop. It allowed us to confidently switch MongoDB drivers. We added a comprehensive (as much as possible anyway) regression test suite to the existing MongoDB driver and then we could simply make the new MongoDB driver pass the same tests.
Even as I write it it sounds obvious, but in an enterprise context it makes sense to reiterate. I like to think about stateful property tests as allowing you to focus only on one method (in Go lingo) at a time. You think of the edge cases of that method in isolation. This let’s you tame combinatorial explosion.
I do agree that we did need to spend a lot of time crafting generators. Also, the rapid library has no classification and no frequency-based generator so we needed to be creative here. Still, it was definitely worth the effort.
I also saw the advantages called out in the integration testing with contract tested fakes section of the original post. Namely:
There are other advantages to using fakes, for example we can use this fake in integration tests with components that depend on the software that we tested with the fake.
and
One of the problems with integration testing against fakes is that the fake can be wrong. The standard solution to solve that problem is to contract test the fake to make sure that it is faithful to the software it’s supposed to be a fake of. We don’t have this problem, because our stateful and parallel property-based tests assure that the fake is faithful
I went into much more details in this 2 part blog post I wrote. Post 1 and Post 2. Thanks for prompting me to write part 2, I procrastinated for a long time 