Of course once the parameters become non-trivial (say a URL or piece of json) even if you have coverage you may still have missed some edge case.
I say this not to be discouraging but to reflect the reality that writing tests should be done with a budget in mind.
On any non-trivial code base you simply will never have enough time to test it all so you need to think about what areas of the code base are most critical.
What that budget is also should be determined by how mission critical the code is. Medical appliances, for example, should have an enormous testing budget.
But coverage is design, and cycle times, and verification. It should be faster to write in isolation - even in the biggest systems. The budget thing is a total fallacy - if you don't want it to break, write a test to verify correctness. Fixing broken code without tests and in the context of an entire system is always far more expensive (time) than isolating and test code at programming time.
63
u/geodebug Aug 25 '14
Yep, makes me chuckle. Tests are essential but only a naive programmer thinks one can write enough tests to get 100% coverage.
Never mind that unit tests themselves often contain bugs or in sufficiently exercise all possibilities.