The more complex the data and the more complex the test code, the harder it is to have a clear reliable unit test.
How do you ensure the tests themselves are accurate? Adding test cases as you encounter errors from newly revealed edge cases means the test didn’t work initially. Unit testing the unit tests is circular logic. You can manually test the unit test, same as you could manually test the code itself.
Typically, unit tests are so simple that bugs are few and easy to spot so this is a non issue, but that same argument can also be made for when the code itself does not need unit tests under the same circumstances.
If the tests are not accurate, then how do you accomplish any of the other points you are trying to make?
The same manager I mention before getting promoted, we were tasked with taking over another existing project where every test was inaccurate. I can guarantee you from experience that all your points fail when the tests are inaccurate.
It actually sounds like you are agreeing with my conclusion, with the exception of thinking bad tests are just fine.
> How do you ensure the tests themselves are accurate?
By adding tests as you build-up and refine code, taking your branch coverage into account, as reported by coverage tools.
If data is too complex, this informs you that the responsibilities of your piece of code needs to be split up into separate components, packages, classes, or whatever. Designing for testability (rather than looks or "design patterns") is one of the most important, if not outright the most important consideration in code organization IMO.
Creating test cases "after the fact" is mostly worthless. TDD, OTOH, gets you best results for a broad range of code bases, but takes a lot of effort, discipline, and energy.
6 comments
[ 1.9 ms ] story [ 27.1 ms ] threadHow do you ensure the tests themselves are accurate? Adding test cases as you encounter errors from newly revealed edge cases means the test didn’t work initially. Unit testing the unit tests is circular logic. You can manually test the unit test, same as you could manually test the code itself.
Typically, unit tests are so simple that bugs are few and easy to spot so this is a non issue, but that same argument can also be made for when the code itself does not need unit tests under the same circumstances.
It isn't about ensuring tests are accurate, it isn't about 100% coverage.
It is about being able to make changes to a running system over time and know that you're not breaking something 10 levels deep.
The same manager I mention before getting promoted, we were tasked with taking over another existing project where every test was inaccurate. I can guarantee you from experience that all your points fail when the tests are inaccurate.
It actually sounds like you are agreeing with my conclusion, with the exception of thinking bad tests are just fine.
By adding tests as you build-up and refine code, taking your branch coverage into account, as reported by coverage tools.
If data is too complex, this informs you that the responsibilities of your piece of code needs to be split up into separate components, packages, classes, or whatever. Designing for testability (rather than looks or "design patterns") is one of the most important, if not outright the most important consideration in code organization IMO.
Creating test cases "after the fact" is mostly worthless. TDD, OTOH, gets you best results for a broad range of code bases, but takes a lot of effort, discipline, and energy.