3 ms·
100% coverage doesn't mean much if you aren't testing that the low-level code is doing the right thing. For example, imagine you're testing a calculator app. Y
by fwip 8y ago
100% coverage doesn't mean much if you aren't testing that the low-level code is doing the right thing.
For example, imagine you're testing a calculator app. Your integration tests make sure that it never crashes, the UI works, basic math is working, etc, but maybe the sin() function is only accurate to two decimal places.
Edit: I do not mean to imply that you, specifically, are missing things. Rather, it is possible to write tests that have 100% code coverage while missing many possible bugs, and I think those risks are increased without the presence of unit tests.
- perfunctory 8y ago> 100% coverage doesn't mean much That's absolutely right. 100% coverage doesn't say much. In fact, by itself it's a pretty meaningless measure of code quality. But the top-down idea still holds. In practice bugs are more likely to happen at the seams between components, and therefore it's where one should test first, not last. It of course depends on the type of the project but I believe it's true for the majority of projects out there.
- achamayou 8y ago100% means nothing, but 30% means something is wrong. Coverage tells you nothing, but the absence of coverage is interesting and useful.