> Markdown version of [/videos/175-how-not-to-test?t=723](https://www.wearedevelopers.com/videos/175-how-not-to-test?t=723). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# How not to test 

Chasing 100% test coverage won't save a poorly architected codebase. Discover why over-mocking hides bugs and how prototyping before TDD actually accelerates development.

- **Speakers:** Golo Roden
- **Event:** World Congress 2021
- **Published:** June 29, 2021
- **Duration:** 43:07
- **URL:** https://www.wearedevelopers.com/videos/175-how-not-to-test

## Summary

The transition from manual code validation to automated testing often forces developers to confront structural flaws in their applications rather than just testing complexities. When code proves difficult to test, it is rarely because the logic is inherently too complex; instead, it is usually because the codebase lacks proper architecture. Shifting toward pure functions—deterministic operations free of hidden states or unpredictable external dependencies—naturally improves testability by minimizing side effects, creating highly reproducible test conditions.

Several common testing misconceptions actively harm code quality, particularly the pursuit of 100% test coverage. Viewing total coverage as an ultimate goal creates a false positive, often driving developers to inappropriately test private methods using reflection or complex inheritance rather than validating that logic indirectly through public interfaces. Over-relying on mocks and stubs introduces a similar false sense of security, as passing tests mean nothing if a mocked database or dependency diverges from its real-world behavior. To prevent this, developers should test mocks against in-memory implementations and guarantee test independence by spinning up containerized, isolated infrastructure from scratch for every execution run, avoiding false passes caused by lingering states.

On the frontend, testing demands treating the user interface as fundamentally asynchronous, accounting for animations and transition states instead of expecting immediate synchronous DOM updates. Granular UI testing should focus on discrete components divided cleanly into "dumb" presentational layers and "smart" state managers, while heavy end-to-end browser automation tools like Cypress or Selenium should be reserved for broader, user-story-driven flows. Finally, while Test-Driven Development (TDD) is an excellent driver of internal code structure, blindly applying it without first establishing an architectural direction is a mistake. Developers should build and discard quick proof-of-concept prototypes before engaging in precise TDD, because just as agile without a strategy becomes anarchy, TDD without a clear goal actively slows development down.

**Keywords:** automated testing pitfalls, pure function testability, code testability architecture, test coverage false metrics, private method testing, database dependency mocking, test environment isolation, asynchronous UI testing, presentational vs smart components, selenium browser automation, cypress end-to-end testing, test driven development (TDD), containerized test infrastructure

## Chapters

1. **Discovering automated testing through early programming experiences** (00:02) — How initial exposure to programming often lacks any concept of automated testing.
1. **Recognizing poorly structured code masquerading as hard to test** (06:00) — Code that feels impossible to test generally indicates poor architecture rather than intrinsic testing difficulty.
1. **Avoiding the trap of testing private code for coverage** (12:03) — Accessing internal state via reflection or inheritance to artificially boost code coverage represents an anti-pattern.
1. **Understanding why total code coverage is a false metric** (17:35) — Chasing full coverage often forces meaningless assertions and unnecessarily blocks automated deployment pipelines.
1. **Evaluating the dangers of over-mocking in integration tests** (21:14) — Relying heavily on fakes and stubs can create a false sense of security that breaks in reality.
1. **Managing test infrastructure and ensuring strict state reset** (28:20) — Automating infrastructure setups for tests guarantees independent execution free from stale states.
1. **Handling inherent asynchronicity when testing UI view components** (30:48) — Effective UI component testing requires strategies to handle asynchronous transitions and logic execution.
1. **Navigating the complexity of cross-browser view regression tests** (34:36) — Managing the fragility and slow execution times of large-scale browser automation suites requires realistic scoping.
1. **Knowing when to bypass test-driven development during prototyping** (38:32) — Strict test-first approaches hinder proof-of-concept exploration and add overhead before clear designs exist.
1. **Adopting a pragmatic approach to reasonable software engineering tests** (41:11) — Prioritizing realistic testing efforts yields better software quality than chasing arbitrary perfectionism or edge cases.

## Related Moments

- [Weighing the benefits and tradeoffs of test-driven development](https://www.wearedevelopers.com/videos/114-why-you-must-use-tdd-now) (from "Why you must use TDD now!")
- [Adopting test-driven design as a strategic development methodology](https://www.wearedevelopers.com/videos/446-treat-yourself-a-tale-about-dog-training-and-test-driven-development) (from "Treat yourself - A tale about dog training and test-driven development")
- [Applying key software design rules to test code](https://www.wearedevelopers.com/videos/515-dirty-tests-and-how-to-clean-them) (from "Dirty Tests And How To Clean Them")
- [Evaluating mocking strategies and user-centric integration testing](https://www.wearedevelopers.com/videos/398-building-the-right-product-and-building-it-right-a-glimpse-into-extreme-programming-atomic-design) (from "Building the Right Product and Building It Right: A Glimpse into Extreme Programming, Atomic Design ")
- [Using test automation as a catalyst for team collaboration](https://www.wearedevelopers.com/videos/1668-how-to-add-test-automation-to-your-project-the-good-the-bad-and-the-ugly) (from "How to add test automation to your project: The good, the bad, and the ugly")
- [The software testing timeline and regression checking pitfalls](https://www.wearedevelopers.com/videos/87-excellent-software-testing) (from "Excellent Software Testing")

## Related Articles

- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)
- [Ignore the Hype: How to Avoid Being Deceived by Technological Trends](https://www.wearedevelopers.com/magazine/528-ignore-the-hype-how-to-avoid-being-deceived-by-technological-trends)
- [The 8 Best Code Testing Tools](https://www.wearedevelopers.com/magazine/402-the-8-best-code-testing-tools)
- [Integration And E2E Testing: Are They Complementary or Interchangeable?](https://www.wearedevelopers.com/magazine/86-integration-and-e2e-testing-are-they-complementary-or-interchangeable)

## Related Jobs

- [QA Automation Engineer](https://www.wearedevelopers.com/jobs/ext/1414297-qa-automation-engineer) at **Bitpanda**
- [Software Tester (f/m/d)](https://www.wearedevelopers.com/jobs/44712-software-tester-f-m-d) at **Power Plus Communications**
- [Engineer, Offensive Security Organization](https://www.wearedevelopers.com/jobs/ext/1992296-engineer-offensive-security-organization) at **Twilio**
- [Senior Web Designer, Growth](https://www.wearedevelopers.com/jobs/ext/102722-senior-web-designer-growth) at **Intercom, Inc.**
- [Staff Frontend Engineer](https://www.wearedevelopers.com/jobs/48313-staff-frontend-engineer) at **SMG Swiss Marketplace Group**
- [Software Engineer](https://www.wearedevelopers.com/jobs/ext/1304673-software-engineer) at **Bitpanda**