This document discusses techniques for adding tests to legacy code, which is defined as code that is difficult to change without tests. It recommends choosing what code to test based on what needs to change now or changes frequently. It describes techniques like writing "pinning" tests that don't change behavior, using the "Three Questions" to identify obstacles to testing, separating behavior from initialization, exposing private methods, wrapping untestable code with proxies, and using factory method injection to inject mocks. The goal is to incrementally add tests to legacy code to enable refactoring it safely.

1. 14 July 2011© Agile Institute 20111CaféTDD?Sure, but What About My Legacy Code?Rob MyersforTest Driven DevelopersBay Area14 Jul 2011

2. What is “Legacy Code”?14 July 2011© Agile Institute 20112

3. 14 July 2011© Agile Institute 20113“Code we’re afraid to change.”-- James Shore“Code without tests.”-- Michael Feathers

4. 14 July 2011© Agile Institute 20114

5. Adding Tests Is Difficult14 July 2011© Agile Institute 20115Circumstantial coupling: "I can’t test this without instantiating half the system!"Peculiar encapsulation: “I wish I could just test that private method!”Duplication:"I'll have to test this on all the subclasses!"Poor cohesion: "This MasterControlClass does everything, so the test will be enormous and complex!"

6. A Conundrum14 July 2011© Agile Institute 20116We add tests to refactor safely.We have to refactor to add safe tests.

7. 14 July 2011© Agile Institute 20117What could possibly go wrong?!

8. Choose Your BattlesTest the code you need to change now (unless it is very difficult)Test the code that changes most often (even if it is difficult)Test the code that haunts your nightmares!14 July 2011© Agile Institute 20118

9. Write “Pinning” TestsWe don’t add or change behavior.We’re not bug-hunting.We aim for coverage.We must see GREEN.14 July 2011© Agile Institute 20119

10. Technique: “The Three Questions”What behavior needs test coverage?What’s preventing us from writing a test?What can we do about that?14 July 2011© Agile Institute 201110

11. Technique:Separate Behavior from InitializationIt’s easier to test behavior when not coupled to initialization code.Use ‘Extract Method’ to preserve existing interfaces.14 July 2011© Agile Institute 201111

12. Before14 July 2011© Agile Institute 201112public void OpenOrderReport(OutputGadget output, string accountNumber) { Account account =LunExData.QueryAccount(accountNumber); Order[] openOrders =LunExData.QueryOrders( "open", accountNumber, DateTime.Now);foreach (Order order in openOrders) { // ...output.Write("Order #" + order.Number); // ... }}

13. After ‘Extract Method’14 July 2011© Agile Institute 201113public void OpenOrderReport(OutputGadget output, string accountNumber) { Account account =LunExData.QueryAccount(accountNumber); Order[] openOrders =LunExData.QueryOrders( "open", accountNumber, DateTime.Now);FormatOpenOrderReport(output, account, openOrders);}private void FormatOpenOrderReport(OutputGadget output, Account account, Order[] openOrders) {foreach (Order order in openOrders) { // ...output.Write("Order #" + order.Number); // ...

14. Technique:Expose A Private Variable or MethodMake a method public (at least accessible to tests)Wrap a variable in getter/setter methods.It may smell really bad.It will eventually be a useful addition to the interface, or will move to another object.14 July 2011© Agile Institute 201114

15. Before14 July 2011© Agile Institute 201115private void FormatOpenOrderReport(OutputGadget output, Account account, Order[] openOrders) {foreach (Order order in openOrders) { // ...output.Write("Order #" + order.Number); // ... }}

16. After14 July 2011© Agile Institute 201116public void FormatOpenOrderReport(OutputGadget output, Account account, Order[] openOrders) {foreach (Order order in openOrders) { // ...output.Write("Order #" + order.Number); // ... }}

17. Technique:Wrap, Then MockAdd a simple delegating Proxy to…Code we cannot change.Final (Java) or sealed (.NET) classes.Classes with no accessible constructors.Anything with a broad (mostly-unused) interface.Feathers’s “Adapt Parameter” is an example of this.14 July 2011© Agile Institute 201117

18. Delegating Proxy14 July 2011© Agile Institute 201118ObjectUnderTest+ MethodToTest()BrainlessProxyXYZZY+ intFoo()+ string Bar(int)+ intFoo()+ string Bar(int)+ double Baz()

19. A New Production Class14 July 2011© Agile Institute 201119public class BrainlessProxy { private XYZZY realOne; public BrainlessProxy(XYZZY theRealXYZZY) {this.realOne = theRealXYZZY; } public virtual intFoo() { return realOne.Foo(); } public virtual string Bar(int parameter) { return realOne.Bar(parameter); }}

20. Tough Problem (Simple Example)14 July 2011© Agile Institute 201120public class TrafficLight { public void SwitchLights() { Color newColor; if (currentColor.IsRed())newColor = new Green(); else if (currentColor.IsGreen())newColor = new Yellow(); elsenewColor = new Red();currentColor.Flash(); Pause(3);currentColor.StopFlashing();newColor.LightUp();currentColor.Off();currentColor = newColor; }

21. Technique:Factory-Method InjectionExtract a Factory Method for the dependency.Let the test create a “Testable” subclass of the Object Under Test.TestableFoo overrides the Factory Method and injects the mock.14 July 2011© Agile Institute 201121

22. Before ‘Extract Method’14 July 2011© Agile Institute 201122public void SwitchLights() { Color newColor; if (currentColor.IsRed())newColor = new Green(); else if (currentColor.IsGreen())newColor = new Yellow(); elsenewColor = new Red();currentColor.Flash(); Pause(3);currentColor.StopFlashing();newColor.LightUp();currentColor.Off();currentColor = newColor; }

23. After ‘Extract Method’ part I14 July 2011© Agile Institute 201123public void SwitchLights() { Color newColor;newColor = NextColor(currentColor);currentColor.Flash(); Pause(3);currentColor.StopFlashing();newColor.LightUp();currentColor.Off();currentColor = newColor;}

24. After ‘Extract Method’ Part II14 July 2011© Agile Institute 201124private Color NextColor(Color currentColor) { Color newColor; if (currentColor.IsRed())newColor = new Green(); else if (currentColor.IsGreen())newColor = new Yellow(); elsenewColor = new Red(); return newColor;}

25. A Small Change14 July 2011© Agile Institute 201125protected virtual Color NextColor(Color currentColor) { Color newColor; if (currentColor.IsRed())newColor = new Green(); else if (currentColor.IsGreen())newColor = new Yellow(); elsenewColor = new Red(); return newColor;}

26. The Test, Part 114 July 2011© Agile Institute 201126public static MockColornewColor;[TestMethod]public void TrafficLightSwitchTurnsNextColorOn() {newColor = new MockColor();TrafficLighttrafficLight = new TestableTrafficLight();trafficLight.SwitchLights();Assert.IsTrue(newColor.WasTurnedOn());}

27. The Test, Part 2Override Just the Factory Method14 July 2011© Agile Institute 201127public class TestableTrafficLight : TrafficLight { protected override Color NextColor(Color currentColor) { return newColor; }}public class MockColor : Color { bool wasLit = false; public override void LightUp() { wasLit = true; } public bool WasTurnedOn() { return wasLit; }}

28. When to Use a Factory Method“I don’t know, but…”If creation of the dependency is buried deep within conditional code.If the Factory Method is (or can be) used in multiple places.If Dependency Injection seems worse (e.g. at a published API).14 July 2011© Agile Institute 201128

29. 14 July 2011© Agile Institute 201129

30. 14 July 2011© Agile Institute 201130

31. 14 July 2011© Agile Institute 201131 Rob.Myers@agileInstitute.comhttp://PowersOfTwo.agileInstitute.com/