Every QA team wants a reliable test suite. But somewhere between sprint planning and production deployment, bad habits creep in. You end up with tests that break randomly, coverage numbers that look impressive but catch nothing, and a team that has stopped trusting the test results altogether.<\/p>\n
These aren’t just annoyances \u2014 they’re testing anti-patterns<\/strong>: systemic mistakes that silently undermine your entire quality assurance effort. Kostis Kapelonis catalogued 13 of them in his classic 2018 article, and nearly a decade later, they’re still everywhere.<\/p>\n Here are the four that do the most damage \u2014 and what to do about them.<\/p>\n Your application has hundreds of unit tests. Every method is covered. The CI pipeline glows green. But somehow, bugs still slip into production.<\/p>\n This is the unit-test-only trap. Teams fall into it for understandable reasons: integration tests are harder to set up, slower to run, and more likely to break. Unit tests, by contrast, are fast and predictable. So teams double down on what feels safe.<\/p>\n The problem? Unit tests only verify isolated pieces of code. They can’t catch integration failures \u2014 database transactions that silently roll back, API contracts that drift out of sync, or deadlocks that only happen under real concurrency. These are the bugs that wake you up at 3 AM.<\/p>\n The fix:<\/strong> Bookmark the test pyramid. Unit tests cover business logic. Integration tests verify that components actually work together. You need both. If setting up integration tests is painful, fix the setup process first \u2014 containers and infrastructure-as-code have made this dramatically easier than it was even five years ago.<\/p>\n This one is subtle but devastating. A developer writes tests that check how<\/em> the code works \u2014 internal fields, private methods, specific object structures \u2014 rather than what<\/em> the code should do from the user’s perspective.<\/p>\n Then the code gets refactored. Suddenly 40 tests break, even though the behavior hasn’t changed. The team now faces a choice: spend hours fixing tests that shouldn’t have broken, or disable them and move on. Most teams choose the latter \u2014 and the test suite starts rotting.<\/p>\n The fix:<\/strong> Write tests against expected behavior, not internal state. Instead of checking that a customer object has a Somewhere, a project manager is demanding 90% code coverage. Somewhere else, a developer is writing meaningless tests that verify getters and setters just to hit the target. Neither of them is improving quality.<\/p>\n Code coverage is the most dangerous metric in testing because it feels<\/em> objective. It’s a number, it goes up, and stakeholders love numbers that go up. But 100% coverage doesn’t mean zero bugs. It means every line was executed \u2014 not that every line was tested meaningfully, or that edge cases are covered, or that the tests assert anything useful.<\/p>\n The fix:<\/strong> Replace coverage targets with better metrics. What percentage of your developers actually write tests? (It should be 100%.) What percentage of production bugs get a regression test written before the fix is merged? What percentage of your tests verify behavior rather than implementation? These are harder to automate, but they actually measure quality. If you must set a coverage number, follow the Pareto principle \u2014 the 20% of your code that causes 80% of your bugs is the part worth covering.<\/p>\n You commit code. The CI pipeline runs. Three tests fail. You investigate \u2014 and find that two of them pass when you rerun the pipeline. The third one is a legitimate regression, but you wasted 20 minutes figuring that out.<\/p>\n Flaky tests destroy trust faster than any other anti-pattern. When developers can’t distinguish between a real failure and a random glitch, they stop paying attention to test results altogether. From there, it’s a short slide to ignoring genuine regressions \u2014 the very thing your test suite was meant to prevent.<\/p>\n The fix:<\/strong> Flaky tests are almost always integration or UI tests with timing issues, shared state, or environment dependencies. Quarantine them into a separate suite that runs independently. Fix the root cause \u2014 retry logic, proper teardown, deterministic test data \u2014 rather than slapping The full list of Kapelonis’s 13 anti-patterns covers everything from treating test code as a second-class citizen to treating TDD as a religion. But these four \u2014 the unit-test-only trap, testing implementation, coverage obsession, and flaky tests \u2014 are the ones that silently kill the most QA strategies.<\/p>\n The common thread? Intentionality.<\/strong> Don’t write tests because you’re supposed to. Write tests that catch real bugs, run reliably, and survive refactoring. That means fewer tests with higher signal \u2014 not the other way around.<\/p>\n Source: Software Testing Anti-patterns<\/a> by Kostis Kapelonis (Codepipes Blog, 2018). Discussion on Hacker News<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Discover the most destructive software testing anti-patterns \u2014 from unit-test-only traps to flaky tests \u2014 and learn practical ways to fix them before they wreck your QA strategy.<\/p>\n","protected":false},"author":2,"featured_media":1345,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[1],"tags":[15,168,181,770,163],"class_list":["post-1346","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-automated-testing","tag-code-coverage","tag-integration-testing","tag-testing-antipatterns","tag-unit-testing"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t1. The Unit-Test-Only Trap (Anti-Pattern #1)<\/h2>\n
2. Testing Implementation Instead of Behavior (Anti-Pattern #5)<\/h2>\n
type<\/code> field set to 1, verify that a registered user can access premium features. Mock collaborators, not implementation details. When the internal structure changes, behavior-focused tests keep passing \u2014 because the feature still works.<\/p>\n3. The Code Coverage Obsession (Anti-Pattern #6)<\/h2>\n
4. Flaky Tests: The Trust Killer (Anti-Pattern #7)<\/h2>\n
retry(3)<\/code> on top and hoping for the best. A small rock-solid test suite is infinitely more valuable than a large one nobody trusts.<\/p>\nBuilding a Test Suite That Actually Works<\/h2>\n