> Markdown version of [/videos/173-how-to-test-a-ball-of-mud](https://www.wearedevelopers.com/videos/173-how-to-test-a-ball-of-mud). 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 To Test A Ball of Mud

Stop using mocks as painkillers for bad architecture. Learn how to tame your monolithic codebase by enforcing strict test independence and deleting obsolete failing tests.

- **Speakers:** Ryan Latta
- **Event:** World Congress 2021
- **Published:** June 29, 2021
- **Duration:** 42:34
- **URL:** https://www.wearedevelopers.com/videos/173-how-to-test-a-ball-of-mud

## Summary

Facing a monolithic "ball of mud" codebase is a grueling reality where extreme complexity makes local changes unpredictable. To escape this trap, software teams must radically shift their methodology rather than simply writing more code to dig themselves out. The first frontline defense is implementing system tests to ensure baseline infrastructure stability. By running simple scripts that verify server uptime and database connectivity, teams guarantee the environment operates correctly before debugging application logic, ultimately removing a massive layer of operational variability from the troubleshooting process.

In parallel, teams should enforce a strict continuous testing habit by appending at least two new unit tests to every work ticket, strictly avoiding the trap of isolating quality assurance into a separate phase or sprint. Writing these tests forces developers to act as external clients of their own code, organically exposing tightly coupled boundaries and poor architecture. Rather than relying heavily on mocking—which acts as a temporary painkiller that masks structural rot and risks creating fragile shadow implementations—engineers should tackle painful dependencies through deliberate redesign and isolation. 

Maintaining strict test independence is another vital pillar for tackling technical debt. Executing test suites in a randomized order instantly exposes hidden state dependencies and teardown failures, preventing cascading false positives. Meanwhile, older, persistently failing tests should simply be deleted, as they only reflect a long-obsolete snapshot of the system. Once infrastructure is stabilized and code-level variability is controlled through proper unit testing, engineering organizations can confidently introduce targeted smoke tests for critical use cases, allowing them to systemically detangle the most daunting architectures without drowning in endless debugging cycles.

**Keywords:** ball of mud architecture, monolithic codebase refactoring, infrastructure stability validation, system test automation, continuous testing habits, unit test design principles, mocking versus isolation, tightly coupled dependencies, test suite independence, test dependency debugging, legacy test deprecation, shadow implementation risks, application smoke testing, variable elimination strategy, software design feedback loops

## Chapters

1. **Characteristics of a ball of mud ecosystem** (00:10) — How inherent unpredictability and high complexity make software systems nearly impossible to navigate.
1. **Writing system tests to verify operational infrastructure** (02:51) — Checking baseline server stability with basic scripts prevents wasted effort diagnosing functional errors.
1. **Rules for forcing unit testing into developer workflows** (10:16) — Enforcing the creation and immediate execution of two new tests per standard work item.
1. **Redefining the testing unit based on real design** (15:41) — Building tests around messy code blocks exposes practical coupling rather than idealized class isolation.
1. **Navigating the risks of mocking code dependencies** (17:44) — Overusing automated mocks hides underlying design flaws and risks validating a shadow implementation instead.
1. **Decommissioning neglected and failing legacy test suites** (21:04) — Continually failing or ignored tests should be deleted completely instead of wasting time restoring past context.
1. **Isolating test execution to achieve reliable feedback** (22:07) — Running random and consecutive executions helps distinguish test state dependency issues from actual code bugs.
1. **Introducing smoke tests for critical application use cases** (28:49) — Full-system verifications become valuable only after lower-level tests eliminate underlying environmental variables.
1. **Adopting a new paradigm to untangle software functionality** (31:29) — Reversing massive architectural decay requires fundamentally different and practically unintuitive practices like rigorous foundation testing.
1. **Handling problematic singletons within legacy software systems** (34:33) — Managing state and controlling component lifecycles requires creative workarounds in heavily coupled singleton patterns.
1. **Evaluating the utility of snapshot and parameterized tests** (36:45) — Extensive test iteration loops often complicate debugging compared to individually asserting explicit functional values.
1. **Unearthing extreme logic bugs embedded inside god classes** (40:20) — Bizarre application architectures sometimes require strange configuration hacks precisely just to reach encapsulated business logic.

## Related Moments

- [Reimagining test automation dynamics as spinning top mechanisms](https://www.wearedevelopers.com/videos/100215-smart-test-automation-the-experience-of-legacy-transformation) (from "SMART Test Automation - the experience of legacy transformation")
- [Navigating legacy systems and unconventional software testing practices](https://www.wearedevelopers.com/videos/557-iot-the-road-to-sustainability) (from "IoT: The road to sustainability")
- [Refactoring architectural messes like the big ball of mud](https://www.wearedevelopers.com/videos/235-antipatterns-nemesis-of-software-development) (from "Antipatterns - nemesis of software 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")
- [Shifting to a culture of continuous proof and best practices](https://www.wearedevelopers.com/videos/100233-when-human-meets-canary) (from "When human meets canary")
- [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")

## 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)
- [What is a Test Plan: Guide to Test Planning](https://www.wearedevelopers.com/magazine/191-what-is-a-test-plan-guide-to-test-planning)
- [Get Old, go Slow, Write Code!](https://www.wearedevelopers.com/magazine/81-get-old-go-slow-write-code)

## Related Jobs

- [Engineer, Offensive Security Organization](https://www.wearedevelopers.com/jobs/ext/1992296-engineer-offensive-security-organization) at **Twilio**
- [Software Tester (f/m/d)](https://www.wearedevelopers.com/jobs/44712-software-tester-f-m-d) at **Power Plus Communications**
- [Senior Engineer, Infrastructure Platform](https://www.wearedevelopers.com/jobs/ext/328836-senior-engineer-infrastructure-platform) at **Intercom, Inc.**
- [Tribe Lead - ( Software) Engineering Centre of Excllence](https://www.wearedevelopers.com/jobs/ext/1475530-tribe-lead-software-engineering-centre-of-excllence) at **SD Worx**
- [Staff, Analytics Engineer](https://www.wearedevelopers.com/jobs/ext/569504-staff-analytics-engineer) at **Twilio**
- [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub**