3 ms·
That doesn't fully test your code. By testing "if a", "if b" separately, you could miss a bug that occurs when a b are both true.
by ec109685 10y ago
That doesn't fully test your code. By testing "if a", "if b" separately, you could miss a bug that occurs when a b are both true.
- amelius 10y ago> That doesn't fully test your code. I didn't say that. Be wary of people who say they fully tested your code :) Anyway, there's another (non-waterproof) approach: try to trigger all possible paths through the code (instead of all basic blocks), but the problem is that the number of paths can increase exponentially with code size. The code-coverage approach, in contrast, is very cost-effecitve. For example, roughly speaking, it triggers all possible exceptions that your code can throw.
- emodendroket 10y ago> The code-coverage approach, in contrast, is very cost-effecitve. For example, roughly speaking, it triggers all possible exceptions that your code can throw. Well, unless you count uncaught exceptions from things your code calls.
- aisofteng 10y agoOr unless you simply forgot to check all possible invalid inputs - which, all of us being human, will happen periodically, even with code review.
- aisofteng 10y agoIt won't trigger exception handling that hasn't been written because you forgot to check a certain sort of bad input. In that case, you may still get 100% code coverage, which many will erroneously take to mean that all possible behaviors are verified. 100% code coverage can _never_ be taken, as a figure, to indicate that testing is comprehensive.
- aisofteng 10y agoBut the goal of unit tests is exactly and specifically to test single cases such as "if a" and "if b", discretely and independently of one another. More complex cases such as "if A and B" are what integration tests are written for.