1. The document discusses techniques for testing legacy production code that was not originally written with testability in mind. This includes unit testing, which allows verifying code works as expected in isolation, and writing tests before making changes to help preserve existing behavior. 2. Testing legacy code can be challenging as the code may have dependencies that are hard to isolate for testing purposes. Techniques to address this include extracting functions to new classes, replacing static dependencies with interfaces, and overriding classes to inject test dependencies. 3. While testing legacy code requires more initial work, it provides long-term benefits like reducing defects, empowering refactoring, and creating a safety net for future changes. The document provides a case study and

1. Testing the UntestableTaming production codeRoy KleinFlash Client Team LeaderWix.com

2. OverviewTest Driven Development OverviewThe motivations for and challenges of testing our production codeTechniques + a real life example

3. Unit TestingExercise classes in an isolated environmentVerify that actions on the code produce predictable, consistent resultsWrite TestsWrite CodePass All TestsRefactor

4. The price of Unit Testing New logic is more time consuming to writeOld logic may require extensive Refactoring to be testableAmount of code to maintain increasesIllusion of being bug free when tests passNo Stage in FlexUnitThe actual visual output can’t be fully tested

5. The benefits of Unit TestingBetter definition and understanding of the code’s purposeHelps improve code designEmpowers refactoringDocuments the usage of the codeA small, quick environment to debug inProvides immediate feedback when the code changes (Adding/modifying functionality, Refactoring, Merging)

6. TDD ROI conclusionsThe price:Initial additional development timeThe benefit:Cumulative reduction in defectsThe conclusion:No brainer for long term projects

7. The ChallengesClasses and functions have multiple responsibilitiesClasses are strongly coupled to other classesSome of these couplings are to SingletonsAmbiguous dependencies (Objects, callbacks)In short, code changes have unknown side effects that are hard to foresee

8. The MotivationOur production code is the result of several years of rat chase Rapid DevelopmentRefactoring core code is dangerousAugmenting core capabilities is expensiveReducing code volatility may save us from a dangerous rewrite, or allow us to reuse code when a rewrite occursMoving to CI is key to remaining competitive

9. Legacy Testing Heuristic Before making the change, write passing tests for the area around your changeThese tests are intended to preserve the behavior of the code prior to your changeAdd failing tests that define the change you’re makingApply your change and make all tests pass

10. Replace Dialog: Dependency Breaking

11. Replace Dialog: Dependency Breaking

12. Case Study 1: Replace Gallery

13. Safe Modification: Function extractionPreserve the original functions’ signature.

14. 1. Preserve function signature

15. Safe Modification: Function extractionPreserve the original functions’ signature. Extract the function to its own class

16. 2. Extract the modified function

17. Safe Modification: Function extractionPreserve the original functions’ signature. Extract the function to its own classCall the new function with the same signature, and a reference to an interface representing the original class

18. 3. Reference original class

19. Safe Modification: Function extractionPreserve the original functions’ signature. Extract the function to its own classCall the new function with the same signature, and a reference to an interface representing the original classUse the IDE to determine what calls are to be redirected to the original class

20. 4. Use IDE to find what’s missing

21. Safe Modification: Function extractionPreserve the original functions’ signature. Extract the function to its own classCall the new function with the same signature, and a reference to an interface representing the original classUse the IDE to determine what calls are to be redirected to the original classPut those calls in the interface

22. 5. Put what’s missing in the interface

23. 5. Put what’s missing in the interface

24. Safe Modification: Function extractionPreserve the original functions’ signature. Extract the function to its own classCall the new function with the same signature, and a reference to an interface representing the original classUse the IDE to determine what calls are to be redirected to the original classPut those calls in the interfaceCreate a mock class implementing the interface for testing

25. 6. Create a mock class

26. Test can now execute!

27. Breaking encapsulation on purposeEncapsulation is a tool that makes the code usage easier to understandThe need to break it often points to problem in the design of the code usageProblems in design can’t be solved without Unit Tests in placeThe break can help in understanding what needs to be changedDamage can be minimized with self documenting code

28. Breaking encapsulation on purpose

29. Solving Singletons dependencyYou can’t use a testing instanceCreate a testing only function to set a testing instance

30. Solving Static dependenciesYou can’t subclass or mock a static classReplace reference to static variables with getters and static functions to local functionsSubclass and override with a test class to use your own data/logicIn case of a massive amount of static calls, use the same class name in your testing project to override the original class, and delegate all calls to another class

31. ConclusionGetting legacy code into a testing environment is possibleMost of the benefits of TDD can be achieved with partial coverageAdapting TDD during any stage of the development is worthwhile. The bigger the project, the more beneficial it is

32. Q & AAgile Principles, Patterns and Practices: Robert Martin