You might think this is a rhetorical question, since Test-Driven Development (TDD) is promoted everywhere. According to TDD, we first write a failing test for a new requirement. Then, in a second step, we write just enough code to make the test pass. Finally, we clean up the code and have the tests as a guarantee that nothing breaks. And then the cycle starts all over again.
But this test-first approach is not used by everyone. And it's even less likely to be used consistently all the time.
A second point is that "writing just enough code" is sometimes harder than expected. At least for me, it often happens that I already have a rough idea of what the code will look like in the end. Without realizing it, I write more code than I actually need for the current test.
But how can we verify that our tests fail when a functionality breaks? How to test our tests?
One approach is Mutation Testing. In this approach, bugs are deliberately introduced into the production code. For example, conditions are inverted or entire statements are removed. The goal is to find out if the tests fail and thus find the built-in bug.
For Mutation Testing, there are libraries that automate the process. But the execution can be very time-consuming. Sometimes manual Mutation Testing is sufficient by modifying the newly written code and seeing if the newly written tests fail.
To test my tests, I usually do exactly this: Just change the code and deliberately introduce errors. If the tests then fail with a helpful error message, even better. That gives me more confidence in my tests.
If the created mutations, automated or manual, are not detected, there may be room to improve the tests, or we may have more code than necessary. However, we should also make sure that production code and test code are not too tightly coupled. Then we run the risk of tests unnecessarily getting in the way of major changes or refactorings.
Therefore: Try to break your code and Happy Testing!
Top comments (0)