Once upon a time…
…there was an Excel file with post-release check steps to be followed manually…
TDD or not TDD ?
Today, I have done pair programming with a fellow developper. He was automating the post-release checks. You know, like : drop some tests files in the input directory, wait a little bit and validate the files are correctly integrated.
So this leads to some code that must really be trusted because we are going to relly on this status to check whether the release is a success or not. As a consequence, my intention has been to unit-test this checking code base !
And here we are : testing the tests.
Benefits and drawbacks
We implemented the post-releases checks with a junit test. So that :
- check results are presented in jenkins for non-developpers
- we do not have to write a check report
- we do not have to write a main program
And we also faced some mixup due to the junit nature of the checks (which are actually in the src/main/java directory !)…
Whereas “testing the tests” could be considered as a waste, we still realized that:
- there was a little over-design on the existing checking process due to the lack of feedback
- TDD helped to produce the minimal checking code without over-design
- we are building healthy confidence about the checks