How To Test A Ball of Mud

Are your unit tests hiding critical design flaws? Learn a two-pronged strategy to confidently refactor even the most tangled codebase.

#1about 2 minutes

Defining the 'ball of mud' software problem

A 'ball of mud' codebase is too complex to understand and its changes have unpredictable results, requiring a different approach like testing to solve.

#2about 7 minutes

Using system tests to verify infrastructure stability

Simple system tests running frequently in CI can confirm infrastructure is operational, which is a critical first step before tackling code correctness.

#3about 4 minutes

Rebuilding testing skills with incremental unit tests

Start by adding two unit tests per work item to gradually build the team's testing skills and integrate testing into the development process.

#4about 3 minutes

Redefining the 'unit' in a complex codebase

The 'unit' in a unit test for a ball of mud is the smallest testable group of code, which reveals the actual system design, not an idealized one.

#5about 3 minutes

Weighing the risks and benefits of mocking

Mocking can ease the pain of dependencies but risks creating a shadow implementation; isolating dependencies by design is a more robust alternative.

#6about 3 minutes

Dealing with legacy tests and test dependencies

Old, failing tests should be deleted, and new tests must be independent to avoid creating a debugging nightmare where test order affects outcomes.

#7about 4 minutes

Strategies for ensuring test independence and speed

Enforce test independence by running tests in a random order and optimize speed by decoupling code from frameworks, not just through parallelization.

#8about 3 minutes

Adding smoke tests for critical application use cases

Once infrastructure and unit tests are in place, add smoke tests for critical use cases to verify high-level application correctness.

#9about 11 minutes

Conclusion and Q&A on advanced testing topics

The talk concludes by summarizing the need for a different approach to legacy code, followed by a Q&A on singletons, snapshot testing, and parameterized tests.