Comment by Mark on "How should I handle the following disagreement in a code review?"

I'm not sure what I can say, it depends mostly on your company policy.

There are not a lot of situations where covering 100% of paths with tests is a desirable goal, even when money is involved (note that 100% of lines != 100% of paths).

In the end, it's about balancing the cost of writing the tests vs the cost of not writing the tests. The cost of writing the test is more obvious: your time, and extra time to run the test suite. But not writing it is harder:

Possible direct loss from defects (the rocket you are building could explode).
Indirect loss from customers considering your product of lower quality.
If the paths have to be tested by hand, that's a big cost, it's probably better to automate it.
In my experience, fixing one bug can take a lot more time than writing a few tests. If you think there's a 20% chance it'll ever break, perhaps write the test just for this point alone.

You can't determine this exactly for individual tests of course, but the company should balance these factors and aim for a reasonable amount of test "coverage" (not a % of lines but a somewhat subjective fraction of reasonable cases).

I'd also suggest comparing to the coverage of other, equally critical code (in your company). If similar code is better tested, you should catch up. If other critical code is hardly tested at all, you'd be better of writing tests for that than adding edge cases for your code.

I'd add that I would personally love to write perfect code with near-100% coverage. If someone more important than me tells me to do it, I'll be happy to comply, despite doubts about profitability. Usually though, they tell me to do less of it because of time constraints.

Search Hashnode