3 ms·
A big issue with TDD is people don't know how to write tests. People tend to write covariant tests where if details of the implementation changes, then the test
by taylodl 2y ago
A big issue with TDD is people don't know how to write tests. People tend to write covariant tests where if details of the implementation changes, then the tests fail, even if the code is working correctly. These tests are easy to write, but bring very little benefit. There's another kind of test that few people write that solves this problem: they're contravariant. The detail implementation can change and yet contravariant tests can test that the code is still working correctly. In other words, you can refactor code and still use your existing tests to ensure the refactor didn't break anything. You don't re-write your test.
Another benefit of contravariant tests? It's very difficult to create them if your architecture and design is poor. Contravariant tests lead to good architecture and design.
Bob Martin discussed these issues in his blog a few years back. https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.html https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContrav...
- voiceofunreason 2y agoIs there any prior art that defines covariant/contravariant tests in this way, or is Martin just borrowing language that sounds cool?
- taylodl 2y agoBob Martin was the first to use the terms covariant/contravariant in the context of software development, as far as I'm aware. Using this precise language borrowed from mathematics at once clarifies both the problem and the solution that folks like Kent Beck and Dan North had been talking about for decades. Now we can discuss these issues with a whole lot less hand-waving.