Next part of my notes from Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C. Martin.
Clean tests
Having clean tests is as important as writing clean production code. Why? Writing poor quality testing code makes it more and more expensive to maintain and extend. After some time tests become less reliable and developers are not willing to use them. Without tests, in turn, they are afraid to refactor production code as it gets vulnerable and prone to errors. In the end poor quality test code results in bad production code.
F.I.R.S.T
Clean tests should meet the following rules that make the acronym:
- Fast. Tests should work fast. If they don’t, we do not want to use them too often. That means we do not find problems fast enough and we do not feel confident to refactor the production code.
- Independent. Tests should not depend on one another and one test should not configure conditions for the next test. We should be able to run each test separately and in any order. If test do not meet this rule, one failing test results in a whole bunch of failures and it is difficult to diagnose the problem on a lower level.
- Repeatable. Tests should be repeatable in every environment.
- Self-Validating. Test should have one output parameter: true or false. We should not need to read any diaries to check if test passed or failed.
- Timely. Tests should be written in the right time. Unit tests should be written just before production code. Otherwise the code may be hard to test.
References
“Clean Code: A Handbook of Agile Software Craftsmanship” – Robert C. Martin
THINK.NET 