In many teams we worked in, test code was treated much less carefully than production code. It was expected to just work. Mindless copy and paste of setup code from one test case to another was never seen problematic, duplications widely accepted, and things were named randomly.

This always leads to problems: gaps in assertions become pretty non-obvious; consolidating long running test suites becomes a cumbersome task; magic numbers need to be changed all across the suite, when they become outdated. Problems like these ("tangles") affect the overall maintainability of our overall code base.

Over the years I identified several good practices ("untangles") to prevent these problems and keep test code maintainable. Some borrowed from general good code quality standards, some specific for test code.

In this talk, I am going to briefly discuss the properties of good test code. Then I’ll present a bunch of good practices and show them applied to an example (in Java). In the end, you should be able to identify tangled code and apply the