If you are a developer you are probably working on a large and complicated codebase. Unfortunately a lot of existing code lacks automated tests and adding them can be challenging, particularly if the code is old or poorly structured. Testability has always been an aspect of architecture that people have said is important but perhaps doesn’t get the attention it deserves.

In order to get a legacy code situation under control, often there’s an initiative to improve the unit tests. This can be difficult if the code is poorly structured.  End-to-end tests can be easier to add and more effective at finding bugs, but are usually too slow to support the kind of code-quality enhancing refactoring efforts you really need. These tests often become prohibitively expensive to maintain too.

There are a couple of techniques I’ve used in these kinds of situations that I’d like to showcase in this talk. Approval testing is similar to characterization testing, and works best on larger pieces of code where you want to test for multiple things. Because of this, the architecture of the system is important for success. Isolation sandboxing is a way to adapt your architecture for testability. You take control of all dependencies and aim to run many instances in parallel.  

It all boils down to applying good engineering to a testability problem. You want to create a situation where you can write tests that have similar bug finding potential as end-to-end tests yet are fast enough and reliable enough to support refactoring. For success you need architectural changes, skill and culture. In this talk I’ll explain how I’ve seen it work in practice.