Property-based testing to the rescueīut what if we could write tests like we write our code? Property-based testing (short: PBT) can help us out here.

The code and tests are designed on different levels of abstraction, where properties are more abstract than concrete examples. The tests we write for it are more the opposite: we write tests that are example-specific and not generic. The code should have certain properties for all possible inputs. When we implement our methods, we want the logic to be generic and not tied to specific cases. And even worse, the scenarios covered are the same every run: essentially coupling between scenario and test suite. Covering all combinations of inputs is just not feasible. And despite all this effort from the team, only a small portion of all possible examples are covered by the tests they wrote. It takes time to see what angles are covered for each method and what is missing or redundant. New developers on the team might also have a hard time grasping the actual intent of the test.

This includes coming up with realistic examples, which requires a thorough understanding of the domain. First of all, developers need to spend more time developing and maintaining these test cases.

There are a few downsides to this approach. If we take a step back, we see that many of these test cases are quite similar, except that each uses a slightly different example.

Kotlin github example