|
|
|
|
|
by netsectoday
2531 days ago
|
|
Bumping the test coverage up past 90% definitely has lines re-run multiple times, with core logic even being re-executed possibly hundreds of times. This is absolutely ok! Your main purpose of writing tests is to make sure when you change business logic that a test will point you to the exact spot. If you commented out any single line of business logic; a test should fail. I understand that this may seem crazy if you are used to 80% coverage, however there are subtle ways to build your unit/integration/feature/security/performance tests where you only pin your public api, and code changes to the internals don't break the tests, and the test suites only have minimal (necessary) overlap. This is test engineering and it takes about a decade of TDD to be comfortable with. I would have said 100% test coverage for 100x but that last 1% isn't worth it. Some things just can't be tested without altering the public interface of your code JUST to accommodate the test, or they require some crazy significant re-work of the code that makes it hard to follow, or you have a module with a crazy way of interfacing with it that makes testing a specific part extremely difficult, or it's code that doesn't really need a test (like a log statement). Side note: 99% test coverage isn't typical but is absolutely necessary if you have automatic patch-management solutions in place and are striving towards zero-defect code. How comfortable would you be pushing to production after bumping the major version of your platform and seeing your test suite pass? Having 99% confidence in this situation is a good thing and saves you time in the long run. |
|