One aspect of Clean Code is that code is testable and tested.
Sonar enables users to import test coverage reports – which show how much of a codebase has been touched by test code. And, good Code Coverage doesn’t necessarily mean you have good tests.
We want to ask you – how do you ensure that your tests don’t just touch your product code, but are testing things in the right way? What practices do you (and your team) encourage when writing tests? What gets in the way sometimes?
I use test-driven development (TDD):
- I write the test code before finishing the main code logic.
- I ensure the test is able to fail.
- I finish the main code logic.
- Now, the test passes, but if one day the main code logic changes, I’m confident the test will be able to fail.
- I run all the tests related to my new main code logic to check its coverage.
- I add the missing tests to complete the coverage, but I start with some wrong exprected results in the tests to make the tests fail.
- Then, I provide the right expected results to make the tests pass.