Testing Strategies for Debt Reduction

Aim for 80% line coverage as a baseline, but focus on branch coverage and mutation score for real quality. A codebase with 70% line coverage and 75% mutation score has better tests than one with 95% line coverage and 30% mutation score. For critical business logic -- payment processing, authentication, data integrity -- target 90% branch coverage and 85% mutation score. For utility code and simple CRUD, 70% line coverage is fine. The worst target is 100% because it incentivizes writing worthless tests for trivial code.

Start with characterization tests that document what the code actually does right now, even if the behavior includes bugs. Do not try to test everything at once -- focus on the modules you need to change first. Use the "seam" technique from Michael Feathers' "Working Effectively with Legacy Code": find points in the code where you can inject test hooks without changing behavior. Write tests that pin down current behavior, verify they pass, then refactor one small piece at a time. Each refactoring round adds more tests until the module is well-covered.

Yes -- flaky tests are one of the most corrosive forms of test debt. When developers see random failures, they start clicking "retry" instead of investigating. Over time, the team develops a habit of ignoring test results entirely, and real failures slip through because "it is probably just flaky." Google research found that even a 2% flake rate causes developers to distrust the entire test suite. Fix flaky tests within one sprint or delete them. Quarantine them in a separate CI job if needed, but never let them pollute the main pipeline. The cost of one undetected production bug is always higher than the cost of fixing a flaky test.

The pyramid is still the best default for most teams. Unit tests at the base give fast, reliable feedback. Integration tests in the middle catch wiring issues between components. A small number of E2E tests at the top verify critical user flows. The "testing trophy" (popularized by Kent C. Dodds) emphasizes integration tests over unit tests, which works well for web applications where most bugs occur at component boundaries. However, it often leads to slower test suites that developers avoid running locally. Start with the pyramid. If you find your unit tests are mostly testing implementation details, shift some weight toward integration tests -- but keep the base heavy for speed.

Code coverage measures which lines your tests execute. Mutation testing measures whether your tests actually detect changes to your code. The difference is critical: a test that calls a function but never checks the return value gets 100% line coverage for that function but 0% mutation score. Mutation testing modifies your source code (creates "mutants") and checks if your tests catch the change. If they do not, you have a test that exercises code without verifying behavior. Think of coverage as "did the test visit this code?" and mutation score as "would the test catch a bug in this code?" Both are useful, but mutation score is the more honest metric.

Track the cost of bugs that reach production versus bugs caught by tests. Calculate developer hours spent debugging production incidents over the last quarter and compare that to the time it would take to write tests for those same code paths. Show that teams with strong test suites deploy 2 to 3 times more frequently with 60% fewer production incidents (data from DORA research). Frame testing not as "quality overhead" but as "deployment confidence" -- the ability to ship features faster because you know they work. Present the numbers: every hour spent writing tests saves 3 to 5 hours of emergency debugging. Management responds to time-to-market improvements and reduced downtime costs, not test coverage percentages.