3 ms·

> Properly, if your code has an ‘if’, you need two tests, for the two branches. Same with every place the outcome may diverge. With this approach, it's basicall

> Properly, if your code has an ‘if’, you need two tests, for the two branches. Same with every place the outcome may diverge. With this approach, it's basically impossible to botch the code if (x % 3 == 0) println "Fizz" if (x % 5 == 0) println "Buzz" There, solved it! And it works fine in all cases you told me to test (e.g. 3, 4, and 5), which means it's impossible I botched anything! Surely I nailed this interview? Seriously though, the criterion you mentioned is only one of many of increasing strictness (see e.g. https://en.wikipedia.org/wiki/Code_coverage#Basic_coverage_criteria https://en.wikipedia.org/wiki/Code_coverage#Basic_coverage_c...), namely branch coverage. Having branch coverage still says very little - the interaction between different branches can be trivially wrong. And desiring full path coverage immediately leads to combinatorial explosion (and the halting problem, once loops are involved). > unless something slips your mind while writing both the code and the tests. That is true for any choice of coverage metric and target.

aasasd 7y ago
> all cases you told me to test (e.g. 3, 4, and 5)! Surely I nailed this interview Well, if you don't see other points where the input→output mapping can diverge (and rely on the client's requirements for that?), then no, you didn't nail it.
- MauranKilom 7y ago
  The point is that you claim to have "the" (best?) way to do proper unit tests, but it still fails in basic cases like some combination of paths through if statements being buggy (even if you properly covered each one in isolation). You normally cannot prove general correctness with unit tests. You can try to probe interesting points in the input space, and different coverage metrics encourage different levels of rigour and effort with this, leading to different fractions of bugs caught, but you'll never have a guarantee to catch all bugs (short of formal proof or exhaustive input coverage).

aasasd 7y ago

> all cases you told me to test (e.g. 3, 4, and 5)! Surely I nailed this interview Well, if you don't see other points where the input→output mapping can diverge (and rely on the client's requirements for that?), then no, you didn't nail it.

MauranKilom 7y ago
The point is that you claim to have "the" (best?) way to do proper unit tests, but it still fails in basic cases like some combination of paths through if statements being buggy (even if you properly covered each one in isolation). You normally cannot prove general correctness with unit tests. You can try to probe interesting points in the input space, and different coverage metrics encourage different levels of rigour and effort with this, leading to different fractions of bugs caught, but you'll never have a guarantee to catch all bugs (short of formal proof or exhaustive input coverage).