--- title: "Legacy Code Hero" url: "https://courses.osherove.com/courses/legacy-code-hero.md" canonical: "https://courses.osherove.com/courses/legacy-code-hero/" tags: [] author: "Roy Osherove" description: "Legacy Code Hero: 5 lessons, 2 h 56 min. A free video course by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Legacy Code Hero [Courses](https://courses.osherove.com/#courses) 5 lessons 2 h 56 min 2 sections [Start course](https://courses.osherove.com/courses/legacy-code-hero/where-do-you-start-with-legacy-code/) [Watch on YouTube playlist](https://www.youtube.com/playlist?list=PLTpyQYhz5CJc) ![](https://courses.osherove.com/img/yt/XCS-9_kC6Kw.jpg) Approaching Legacy Code with a Test Driven Attitude The Problem You have been trying to learn [TDD](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_27 "Test-driven development (The Art of Unit Testing, 3rd ed., ch. 1)"), and it’s going pretty well, but your code looks horrible. It is really hard to test. Your design skills are lacking, and trying to let TDD drive the design without having design skills can lead to a very problematic, although testable, design of your code. Objectives I believe that separating the learning about the core skills of [Unit Testing](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_17 "Defining unit testing, step by step (The Art of Unit Testing, 3rd ed., ch. 1)"), TDD, and Design should be separated so that the learner will not feel overwhelmed. This course is a complement to the Art of Unit Testing course I am teaching. This course is specifically dealing with [legacy code refactoring skills](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-10 "Working with legacy code (The Art of Unit Testing, 2nd ed., ch. 10)"), and assumes that you already know how to write unit tests. Assumed: You already have some experience writing unit tests. - [Design for Testability](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-11#ch11lev1sec2 "Design goals for testability (The Art of Unit Testing, 2nd ed., ch. 11)") - [Refactoring patterns](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec5 "Variations on refactoring techniques (The Art of Unit Testing, 2nd ed., ch. 3)") on hard to test legacy code - Writing tests against refactored code - When it does and does not make sense to refactor We will also take a look at open source projects and try to see how we would refactor them. ## About this course Roy Osherove describes [legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12 "Working with legacy code (The Art of Unit Testing, 3rd ed., ch. 12)") as [code that people are afraid to touch](https://osherove.com/blog/2005/6/5/whats-legacy-code.html "What's legacy code? (osherove.com)"), and names dependencies as its biggest problem. He covers how to choose [which classes to test first](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12#sigil_toc_id_221 "Where do you start adding tests? (The Art of Unit Testing, 3rd ed., ch. 12)") and how to wrap a system in acceptance and [integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_25 "Integration tests (The Art of Unit Testing, 3rd ed., ch. 1)") before changing it. The rest of the course shows refactorings such as [extract interface](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_74 "Extracting a common interface (The Art of Unit Testing, 3rd ed., ch. 3)"), [extract and override](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec5 "Variations on refactoring techniques (The Art of Unit Testing, 2nd ed., ch. 3)") and instance delegator that create [seams](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec4 "Refactoring your design to be more testable (The Art of Unit Testing, 2nd ed., ch. 3)") for [fakes](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2 "The difference between mocks and stubs (The Art of Unit Testing, 2nd ed., ch. 4)"), with code demos that include the open-source BlogEngine.NET project. ## Related reading - [Mock Objects vs. "Inherit & Override"](https://osherove.com/blog/2005/6/16/mock-objects-vs-quotinherit-amp-overridequot.html) · osherove.com From the lesson [Extract And Override Focus](https://courses.osherove.com/courses/legacy-code-hero/extract-and-override-focus/): Roy compares mock objects with subclassing and overriding a virtual method, the technique shown slowly in this lesson. - [Where do you start adding tests?](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-10#ch10lev1sec1) · The Art of Unit Testing, 2nd ed., ch. 10 From the lesson [Where Do You Start with Legacy Code?](https://courses.osherove.com/courses/legacy-code-hero/where-do-you-start-with-legacy-code/): The 2nd edition's section on where to start adding tests, ranking components by logic and dependencies as the quadrants do. - [Test Driven Validation Logic with Extract & Override](https://osherove.com/blog/2012/5/16/test-driven-validation-logic-with-extract-override.html) · osherove.com From the lesson [Extract And Override With Validation Logic](https://courses.osherove.com/courses/legacy-code-hero/extract-and-override-with-validation-logic/): Roy test-drives validation logic with extract and override, the same technique used here on the password validator. - [Refactoring your design to be more testable](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec4) · The Art of Unit Testing, 2nd ed., ch. 3 From the lesson [Refactoring Hardcore Skills](https://courses.osherove.com/courses/legacy-code-hero/refactoring-hardcore-skills/): The 2nd edition's section on refactoring a design to be testable, covering extract interface and constructor injection shown here. - [Tips for Testable code and for testing legacy code](https://osherove.com/blog/2007/6/10/tips-for-testable-code-and-for-testing-legacy-code.html) · osherove.com From the lesson [Instance Delegator Focus](https://courses.osherove.com/courses/legacy-code-hero/instance-delegator-focus/): Roy's consulting notes on getting a hard-to-test business method in legacy code under test. ## Curriculum Section 1 ### Starting Out 1 lesson · 50 min This section is a talk on deciding where to start with legacy code, based on how many dependencies and how much logic each class has and on which code is in active development or causing problems. Roy Osherove argues for covering the system with integration and acceptance tests and an automated build that runs them continuously before refactoring, with unit tests filling in later. 1. [Where Do You Start with Legacy Code? Duration 50:03](https://courses.osherove.com/courses/legacy-code-hero/where-do-you-start-with-legacy-code/) 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. Section 2 ### Refactoring 4 lessons · 2 h 6 min This section covers refactorings that make legacy code testable without changing its functionality, including extract interface, extract and override, parameterized constructor, break out method object, adapt parameter, static setters and instance delegator. Two lessons apply instance delegator and extract and override in detail, to a static manager class in BlogEngine.NET and to a login manager that calls static dependencies. The last lesson uses extract and override to write password validation logic with test-driven development. 2. [Refactoring Hardcore Skills Duration 46:58](https://courses.osherove.com/courses/legacy-code-hero/refactoring-hardcore-skills/) 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. 3. [Instance Delegator Focus Duration 13:44](https://courses.osherove.com/courses/legacy-code-hero/instance-delegator-focus/) 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. 4. [Extract And Override Focus Duration 21:17](https://courses.osherove.com/courses/legacy-code-hero/extract-and-override-focus/) 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. 5. [Extract And Override With Validation Logic Duration 43:35](https://courses.osherove.com/courses/legacy-code-hero/extract-and-override-with-validation-logic/) 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. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/