Legacy Code Hero

Roy Osherove discusses definitions of legacy code and why dependencies make it hard to change, then sorts classes into four quadrants by their number of dependencies and amount of logic to decide where to start testing. For most teams he recommends starting with the easy classes. He then describes wrapping a web project in smoke, security, load speed and page weight tests, built with TeamCity and FinalBuilder scripts that run Cucumber with Capybara or PhantomJS.

Roy Osherove goes through refactoring patterns, many of them from Michael Feathers' book Working Effectively with Legacy Code: extract interface (with a fake email sender and a look at inversion of control containers such as Microsoft's Unity), extract and override, parameterized constructor, break out method object, adapt parameter, static setters on singletons, and instance delegator on a static class from BlogEngine.NET. He closes by saying none of these refactorings can be done without acceptance tests, and that testability and good design are not the same thing.

In BlogEngine.NET, Roy Osherove looks at the static Send method of a manager class, which scans a new post for links and sends trackbacks or pings, and explains why the static class and the blog settings singleton block extract and override. He copies the method into a non-static version, makes the static method forward to a new instance, and extracts virtual methods such as the enable trackback send check so a testable subclass can override them. He ends with an exercise: write unit tests for when trackbacks and ping backs get sent.

Roy Osherove applies extract and override to a login manager that calls a static logger: the call moves into a protected virtual method with as little logic as possible, which a testable subclass overrides to save the message for the test to check. He extends the example to a logger that throws an exception, a call to a static web service and the machine name, then shows extract and override returning fake objects. He also answers a question on whether extracted methods should be protected or public.

Roy Osherove explains how to test validation code that combines many rules, using a password validator, by testing each rule separately from the logic that combines them. He introduces extract and override, also called the test specific subclass pattern, with a testable subclass that overrides the current time so a check does not have to wait seven days. He then writes a validator test first, with flags in a testable subclass that set what each rule returns, and tests a single rule method directly using the InternalsVisibleTo attribute.