Every QA team starts with good intentions. You write tests, you automate pipelines, you track coverage — but somewhere along the way, things start feeling off. Tests break for no reason. Developers complain about slow feedback loops. Coverage numbers look great, yet bugs still slip into production.
If any of that sounds familiar, you might be dealing with software testing anti-patterns. These are recurring habits and structural choices that seem reasonable in the moment but quietly erode the value of your test suite over time. Kostis Kapelonis, in his comprehensive guide on testing anti-patterns, catalogued 13 of the most common ones — and they apply regardless of your programming language or tech stack.
Here are four of the most damaging anti-patterns every QA professional should know — and how to fix them.
1. The Unit Test vs. Integration Test Imbalance
This is easily the most common anti-pattern in the wild. Some teams have only unit tests and rely on production to catch integration-level bugs. Others go the opposite direction and have only integration tests, skipping unit tests entirely because they seem like “extra work.”
Both approaches are broken. A team with only unit tests can never catch database transaction failures, API contract mismatches, or timeout issues — those are integration-level concerns by definition. Meanwhile, a team with only integration tests faces a different nightmare: slow feedback loops, complex debugging, and an explosion of test scenarios. As Kapelonis illustrates, a service with four modules — each having 2, 5, 3, and 2 code paths — needs only 12 unit tests but a staggering 60 integration tests to cover the same logic. Most teams that try the “integration-only” route end up cheating with a “representative” subset, leaving critical corner cases untested.
The fix: Use both. Unit tests handle business logic and edge cases; integration tests verify that the pieces connect correctly. The shape of your test pyramid should reflect your application — a command-line tool needs more unit tests, a payment gateway needs more integration tests, and a browser-based design tool needs more UI tests. There is no one-size-fits-all ratio.
2. Testing Internal Implementation Instead of Behavior
Imagine you have 40 tests that all check a single field called customerType on a Customer object. Then the business decides to add affiliate users, and suddenly that field is replaced by a foreign-key relationship. All 40 tests break — not because the business logic changed, but because the tests were coupled to the internal structure of the object rather than the behavior it should exhibit.
This is the hallmark of tightly coupled tests. When every new feature forces you to refactor dozens of existing tests, the team eventually loses trust in the test suite. Developers start skipping tests, managers declare testing a waste of time, and the whole practice collapses.
The fix: Write tests that verify business outcomes, not internal fields. Instead of testing what customerType equals, test that loginAsGuest() works, that register() creates a valid account, and that getPremiumDiscount() returns the correct amount. When the internal implementation changes, only the setup code needs updating — not the verification logic.
3. Code Coverage Obsession
Code coverage is the most seductive metric in software testing. It’s easy to measure, easy to understand, and easy to weaponize in a management meeting. But here’s the uncomfortable truth: 100% code coverage does not mean zero bugs.
Coverage tells you which lines of code were executed during a test run — not whether they were tested correctly, not whether edge cases were covered, and certainly not whether the tests verify meaningful behavior. Teams that chase coverage numbers invariably end up writing trivial tests for getters and setters, inflating the metric while adding zero protection against real regressions. The Pareto principle applies here: roughly 20% of your code causes 80% of your bugs. Focus your testing energy there.
The fix: Replace coverage targets with more meaningful metrics. Kapelonis proposes the Codepipes Testing Metrics (CTM): percentage of developers writing tests, percentage of production bugs that get a corresponding test added, percentage of tests that verify behavior (not implementation), and percentage of deterministic tests. These are harder to gamify and far more indicative of testing health than a single coverage number.
4. Flaky Tests Erode Trust
Even a small number of flaky tests can destroy the credibility of an entire test suite. When a build fails and the team’s first reaction is “oh, it’s probably just that flaky test again,” you’ve already lost. Developers stop investigating failures, real regressions slip through, and the test suite becomes background noise.
Flaky tests are almost always integration or UI tests — the higher you go in the test pyramid, the more environmental variables come into play. Network latency, database state, browser rendering quirks, and race conditions all contribute to non-deterministic results.
The fix: Quarantine flaky tests into their own suite while you investigate the root cause. Maintain a “rock solid” core suite that always passes when the code is correct — a failure in this suite should stop a release. Common fixes include adding retry logic with exponential backoff, using stable test data (not shared state), and isolating external dependencies with mocks or test containers. If a test cannot be made deterministic, it belongs in a separate, non-blocking pipeline.
The Bigger Picture: Testing Is a Craft, Not a Checklist
Kapelonis also covers anti-patterns like treating test code as a second-class citizen, running tests manually, ignoring documentation, and blindly following TDD as a religion. The common thread is clear: testing is a discipline that requires thought, not ritual.
If you’re inheriting a legacy project with no tests, start by writing tests for production bugs as they get fixed. If your team is greenfield, invest time in learning your testing framework’s advanced features — parameterized tests, proper mocking, and test categorization — before writing a single test. And if someone on your team proudly declares that “all tests are a waste of time,” dig deeper. They’ve probably been burned by one of the anti-patterns above.
The good news? Every anti-pattern is fixable once you recognize it. The bad news? There are probably more than 13 hiding in your codebase. The best time to start looking was yesterday. The second-best time is now.
Source: Software Testing Anti-patterns by Kostis Kapelonis (Codepipes Blog). Originally discussed on Hacker News with 465 points and 166 comments.
Leave a Reply