Unit tests are useful, but they cannot prove that an application works with its real dependencies or completes a user journey. The practical lesson behind “The Best Engineers I Know Don’t Write Unit Tests” is not to stop writing unit tests; it is to choose tests for the risks they can actually expose. A sound strategy combines fast, isolated checks with integration tests and a small number of end-to-end tests for critical flows.
What the provocative title gets right—and wrong
Tarek Mostafa’s DEV Community article argues that mock-heavy unit tests can become checks of assumptions encoded in mocks rather than checks of behavior against real dependencies. That is a useful warning about overconfidence in isolated tests, not evidence that experienced engineers avoid unit testing. The article itself recommends unit tests for isolated algorithms such as cryptographic functions, parsers, and mathematical logic. Its broader claims about what the “best” engineers do are the author’s argument, not an independently established finding. Read Mostafa’s article.
As an Amazon Associate I earn from qualifying purchases.
Mostafa also recounts a payment-service incident and reports 94% code coverage and a 30% engineering-time cost. Those figures are reported in his article; the available sources do not independently verify them, so they should not be treated as general evidence about coverage or engineering productivity.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What each test layer can establish
Google’s testing guidance distinguishes the layers by what they exercise. A unit test checks a functional unit, commonly with external dependencies mocked or faked. An integration test checks a small group of units working together. An end-to-end test exercises a product journey as a user would. These tests answer different questions, so a pass at one layer does not establish that the others will pass. Google Testing Blog: “How Much Testing Is Enough?”
- Unit: Does this function or component produce the expected result for the inputs and conditions under test?
- Integration: Do the components and boundaries work together—for example, does application code interact correctly with a database or service?
- End-to-end: Can a user complete an important product journey through the system?
Isolation usually makes a test faster and helps narrow down a failure. But when a test replaces a dependency with a mock or fake, it only checks the behavior that the substitute models. A mismatch between that model and the real dependency can survive a passing unit test. Integration tests can expose some of those interaction defects, at the cost of more setup and potentially slower, less isolated feedback.
Why coverage percentage is not a quality guarantee
Coverage can show which code a test suite reaches, but a high percentage alone does not show that tests assert the right behavior, use realistic collaborators, or cover critical user journeys. A team-wide coverage threshold can be a useful prompt to investigate untested code, but it cannot stand in for judging risk and test quality. Mostafa’s cited 94% figure is an anecdote from his article, not proof that high coverage caused the reported incident or that a particular threshold is ineffective.
Google’s 2015 guidance offered a first-guess distribution of 70% unit tests, 20% integration tests, and 10% end-to-end tests. It explicitly presented that mix as a rule of thumb that varies by team, not a mandate or research finding. Google Testing Blog: “Just Say No to More End-to-End Tests”
Google’s 2024 discussion likewise treats the test pyramid as a heuristic: teams generally want more unit tests than integration tests, and more integration tests than end-to-end tests, while accounting for speed and fidelity trade-offs. It is a way to think about a suite, not a quota to apply regardless of product. Google Testing Blog: “What Is the Test Pyramid?”
Rank #3
Choose tests by risk and feedback value
For each important behavior, ask what failure would matter and which test can reveal it reliably and quickly. Consider:
- Speed: How quickly will developers learn that a change broke something?
- Diagnosis: Will a failure point to a small unit or leave the team tracing a large system?
- Fidelity: Does the test use the real boundary or a substitute whose behavior could differ?
- Reliability: Is the test repeatable, or does it fail intermittently?
- Cost: What setup and maintenance does the test require?
- Coverage of risk: Which interactions or user journeys does the test actually exercise?
Use unit tests where isolated logic has meaningful edge cases and a fast, precise check is valuable. Add integration tests around boundaries where configuration, serialization, persistence, or dependency behavior could invalidate assumptions. Use end-to-end tests for a small set of high-value journeys, rather than asking them to cover every branch of the codebase.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Build a layered suite, not a test-count target
- Identify consequential behavior. Start with the product’s critical operations and the failures users or the business cannot readily tolerate.
- Test deterministic logic in isolation. Cover important rules and edge cases with unit tests when doing so gives fast, clear feedback.
- Exercise important boundaries together. Add integration tests where correctness depends on multiple components or real dependency behavior.
- Verify critical journeys end to end. Check that the user-facing flow works across the system, while keeping this layer focused enough to maintain.
- Review failures and gaps. When a defect reaches production, ask which layer could have detected it and whether adding that check would be reliable and worth its cost.
Google’s guidance emphasizes that the right amount and shape of testing depends on “the type of software, its purpose, and its target audience.” The useful standard is therefore not a universal coverage percentage or a fixed ratio, but a suite whose different layers give timely, trustworthy evidence about the risks that matter for the product.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
