4 ms·
That's because you have such simple conditions. How do you compute them? if (x < y) { ... } really changes things. Did you test for x === y? for NaN? for v
by spankalee 5y ago
That's because you have such simple conditions. How do you compute them?
if (x < y) { ... }
really changes things. Did you test for x === y? for NaN? for very close doubles that should have passed/failed for business reasons? For types other than numbers if your language allows?
Expressions can have any number of edge cases that code coverage can't account for.
- Supermancho 5y agoDepends on the language/type safety offered. If your language has a NaN (javascript) and you can assert the expected behavior of x < NaN (false) or if you don't even want to encounter that, then you're able to reason back to the generation of the inputs. Wherever x and y came from, if there was a possibility of an NaN being a value, you want the generating function to exception or cast via some sort of validation before handing them off to other unsuspecting functions.
- thaumasiotes 5y agoWell, imagine two different analyses of the code: 1. Does each branch do the right thing? 2. Does the code go down the correct branch in the first place? I've focused more on the first question, and you're focusing more on the second. But it's fair to say that each question is a reasonable focus of testing, which weakens my comment above.