---
title: "Extract And Override Refactoring"
url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/extract-and-override-refactoring.md"
canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/extract-and-override-refactoring/"
tags: []
author: "Roy Osherove"
description: "Lesson 14 of 21 in The Art of Unit Testing and TDD in Java (Day 3), 13:35. Free video 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/"
---

# Extract And Override Refactoring

1. [Courses](https://courses.osherove.com/#courses)
2. [The Art of Unit Testing and TDD in Java](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/)
3. Day 3

Lesson 14 of 21

Duration: 13:35 [Watch on YouTube](https://www.youtube.com/watch?v=k0g4mi5_iVE)

In this talk we learn about the [Extract and Override Refactoring](https://osherove.com/blog/2005/6/16/mock-objects-vs-quotinherit-amp-overridequot.html "Mock Objects vs. \"Inherit & Override\" (osherove.com)"), and why it is one of the coolest things you should know.

## In this lesson

Roy Osherove separates [constrained isolation frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev2sec1 "Constrained frameworks (The Art of Unit Testing, 2nd ed., ch. 6)"), which cannot override static or private methods, from unconstrained ones such as [JMockit](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev1sec1 "Constrained and unconstrained frameworks (The Art of Unit Testing, 2nd ed., ch. 6)") and PowerMock, which can [fake](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)") them. Without them, he applies [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)") to a [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)") that calls a static logger: the call moves into a protected call logger method, which a [testable subclass](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_95 "Partial mocks (The Art of Unit Testing, 3rd ed., ch. 4)") in the test overrides to save the text in a public field. He also explains [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)"), keeping logic out of the extracted method, and starting [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)") with [integration tests before refactoring](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12#sigil_toc_id_225 "Writing integration tests before refactoring (The Art of Unit Testing, 3rd ed., ch. 12)").

## Transcript

2,051 words

[\[00:08\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=8s) >> Okay. >> Hello. So up until now we've dealt with standard things instance methods, virtual methods, things that we can override. But what happens when we we we come across things that we can't easily override? we can't replace the instance of things because maybe a class doesn't receive an interface. Maybe a class uses static methods of a logger. Well, this is where we start looking at other ways to test our code.

[\[00:44\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=44s) Now, before we do this, I want to mention that there are two types of [isolation frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-5#sigil_toc_id_99 "Defining isolation frameworks (The Art of Unit Testing, 3rd ed., ch. 5)"). There are constrained and [unconstrained isolation frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev1sec1 "Constrained and unconstrained frameworks (The Art of Unit Testing, 2nd ed., ch. 6)"). Now, the [constrained isolation frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev2sec1 "Constrained frameworks (The Art of Unit Testing, 2nd ed., ch. 6)") basically work like we've done so far. We create a class that inherits from something then we override the methods we care about. But also that means that those frameworks have the same constraints that we have as developers. We cannot override a static method for example. We cannot override a private method or a constructor

[\[01:17\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=77s) Unless we unless we have some kind of special tool. Otherwise we have to override to sorry to refactor things. So unconstrained frameworks allow us to basically test our code without changing it. Those include JMockit which is both a test framework but it can also run within [JUnit](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2#sigil_toc_id_39 "The xUnit frameworks (The Art of Unit Testing, 3rd ed., ch. 2)") and it also includes the ability to fake static methods, private methods and other things and PowerMock which is an addition

[\[01:50\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=110s) An additional framework that you can use within EasyMock or Mockito and I'm going to explain about those and how you can use them but first I want to show how we don't have to use them if we don't have to. So I'm going to show a very common technique to refactor your code even if it uses static methods. And we're going to practice to use this technique. I'm calling it [extract and override](https://osherove.com/blog/2012/5/16/test-driven-validation-logic-with-extract-override.html "Test Driven Validation Logic with Extract & Override (osherove.com)") so that we can learn how to refactor our code

[\[02:20\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=140s) From its dependencies. So extract and override is basically a way for us to look at something that calls something we don't control and then extract the call to that something. Let's say it's a logger and make it into a separate method that just contains the call to that logger and then we inherit the class the actual class that contains the call. So if the class is [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)") and it calls a logger, we actually inherit

[\[02:51\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=171s) In our tests from string calculator and we override the virtual method we just extracted. It sounds kind of complicated, but it really isn't. So let's say that we have this class. It's a class called static logger. It has a static method and we obviously can't use it. And what we'd like to do is to prove that is to prove that we actually call static logger when we should.

[\[03:23\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=203s) So in our what I'm going to show you is a class called string calculator with statics. And in there there is already a call to static logger. So now we're kind of getting into [legacy code](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)") land a little bit. How do you prove that maybe there is a bug in the call? Maybe there's a missing space or an extra space that shouldn't be there. And we want to prove that before we change the code in the call to the static logger. So one way we can do this without using things like PowerMock is by extracting just that line where we call static logger into its own little method.

[\[04:01\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=241s) Before we use PowerMock, let me just show you how we can achieve this without things like power. So here we have the class and this is the line that we care about static logger.write but I want to make this class more testable. Obviously I cannot test that static logger was called with regular methods. So what I'm going to do is I want to be able to write this test

[\[04:31\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=271s) Add always calls the static logger. That's what I want to prove. Maybe it doesn't, maybe it should, but I'm not even sure where to start. So, I'm going to make it testable first. And when we deal with legacy code, some of the rules of [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)") don't make sense anymore. For example, sometimes you have to refactor your code before you can test it as a [unit test](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)"). But of course, before you can refactor your code so you can make it testable, you have to have some kind of [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)") so that you know you didn't break anything by refactoring to make it testable so that you can test it.

[\[05:03\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=303s) See, it's a very simple idea. You start with integration test so that you can refactor your legacy code and then you can add unit tests. Okay. So what do I do? I just select this line and I extract the method. Now notice that the string that I sent to the logger is not I took the int and the string and I made it into a single parameter because what I don't want to happen is that in the virtual method I'm going to create I don't want there to be any logic whatsoever

[\[05:39\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=339s) Because if there is logic I'm going to be overriding that in my test. So I won't be able to test that logic. So what I what I'd like to do is to also know that the text being sent is correct. So I don't want to have any logic in my tests and I want to not override any logic in my tests. So I'm going to make the extract method the simplest method I can think of. So I'm just going to call it call logger.

[\[06:11\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=371s) So I have this method call logger. Now I have this call. I'm going to make it protected so I can override it. And that's basically it. You know this is a very very simple method. I have call logger here. And the idea of refactoring is changing the code without changing the functionality. And the code does exactly the same as it did before. The only difference is that now I have a way to to test it. So what I've done actually is created what what's called a [seam](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)").

[\[06:45\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=405s) A seam is when you have for example fabric and you want to connect two pieces of fabric. So all our clothes are made of many many seams. It's where things connect to each other. So a seam is also where you can inject or replace or override dependencies in your tests. The more seams you have in your code, the more testable it is basically. So here we've created a seam because we have a method that is virtual by default that only handles the dependency.

[\[07:16\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=436s) Yes of course I could have overridden parse single number but then I wouldn't be able to test all the logic inside it. So I don't want to override that. I want to only create a method that I override that will [break the dependency](https://osherove.com/blog/2005/8/23/issues-in-breaking-dependencies-for-unit-testing.html "Issues in breaking dependencies for unit testing (osherove.com)") to the static logger. And now just like I did with a [mock object](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_76 "Interaction testing, mocks, and stubs (The Art of Unit Testing, 3rd ed., ch. 4)"), I can assume that I have this what's called a mock method. So I assume that if the method got called, then the static logger got called. So how do I do that? If I go to my test, the first thing I'm going to do is that in my test class, I'm going to create a new class and I'm going to call it testable

[\[07:53\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=473s) String calculator with statics because that's the name of a class that I'm overriding. I'll say I'm extending string calculator with statics. Now this is the first time we've done this in all of this course is that we actually inherit from the class we are about to test. But we are going to inherit all the implementation of that class and we're only going to override a single method in that class.

[\[08:30\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=510s) So here I might say override and then paste that in. And now I can override that method. And notice that I'm using the override annotation here. This is just an optional annotation that I can use so that my compiler will tell me if I got the name of the method wrong for example. So if I do this I can see a little error here.

[\[09:01\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=541s) There is no such method. It's just a helper for me. Okay. So I override this and now I'm going to treat it just like we did with all the fake classes we hand written before. I'm going to take the text. I'm going to say written equals the text we just got. And what is written? Let's just make it a field on the class. Make it public so that we can assert against it. That's about it.

[\[09:32\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=572s) So now we have this whole class and that's the class we're actually going to use in our tests. So now in my test I'm going to create a testable string calculator with statics new testable

[\[10:03\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=603s) And once I've created I can basically say let's see did I get it wrong? Yeah, I should have said string testable mistake. Now the next thing is I'm actually going to call SC.add because that's my requirement. And last thing I have to do is just assert equals that I get back one to

[\[10:34\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=634s) The written. So this is almost like closing a circle. It goes back to when we just started with using our own little fake classes. Only this time the fake class is the real class, but the only thing fake about it is a single method. Everything else is the real implementation. So we break the dependency on the static logger by overriding the method that calls it. And so if the field has one, we can assume that the static logger method actually got that text because there is very little logic that we override.

[\[11:12\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=672s) We can be pretty certain that things are okay. This is called extract and override questions. answers. Does anyone want me to repeat this? >> Yeah, the call logger. This is what it looks like. >> Yes, this is the extraction and this is what it looks like. >> You had to do the extraction because you couldn't override the static right directly.

[\[11:42\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=702s) That you can override the call. >> I had to do the extraction because not because I couldn't override the call to parse single number but I couldn't override a call to a static logger. You cannot override a call to a static method because there is nothing to replace. There is no instance of anything. So whenever we have something like that and by the way this works for anything creating a new logger creating a static logger calling a database anything you can extract the call to that dependency as simple as possible and then override that method that allows you to break anything you want.

[\[12:19\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=739s) Now, this is so easy to do once you get used to it that I call this extract an override because it's you're like addicted to it. Once you go into legacy code, this is much easier to do than extracting an interface into the system because it's much less work. Extracting an interface into the system makes you extract a whole new class. This allows you to just override a single method. This is also good for cases where you want to have a method that has a lot of logic, a lot of checking like validation.

[\[12:51\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=771s) You want to check that the person name is that and that the XML is this and the database is there and all these five things maybe have to be true. And you can override each of them make them each virtual methods and then override them like flags and say create a testable version where this flag will return true. This flag will return false. This flag will return true. Let's see what happens. So you can play with it in a very very easy way. But you have to learn how to do it first. More questions.

[\[13:27\]](https://www.youtube.com/watch?v=k0g4mi5_iVE&t=807s) Okay. So we're going to continue from where we left off yesterday. But from the part that where it says after demo for extract and override.

## Related

- [Variations on refactoring techniques](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec5) · The Art of Unit Testing, 2nd ed., ch. 3

    The 2nd edition's section on variations on refactoring techniques, which includes extract and override.

- [Mock Objects vs. "Inherit & Override"](https://osherove.com/blog/2005/6/16/mock-objects-vs-quotinherit-amp-overridequot.html) · osherove.com

    Roy's post comparing mock objects with inherit and override, the subclass-and-override technique taught here.

- [An object-oriented partial mock example](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4) · The Art of Unit Testing, 3rd ed., ch. 4

    The 3rd edition's object-oriented partial mock example, overriding a method in a testable subclass.

- [Test Driven Validation Logic with Extract & Override](https://osherove.com/blog/2012/5/16/test-driven-validation-logic-with-extract-override.html) · osherove.com

    Roy test-drives validation logic with extract and override, another worked example of the refactoring.

- [Writing integration tests before refactoring](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12#sigil_toc_id_225) · The Art of Unit Testing, 3rd ed., ch. 12

    Section on writing integration tests before refactoring, the advice for starting with legacy code here.

### Also linked in this lesson

#### The Art of Unit Testing, 3rd ed.

- [Partial mocks](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_95), ch. 4
- [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12), ch. 12
- [Defining isolation frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-5#sigil_toc_id_99), ch. 5
- [The xUnit frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2#sigil_toc_id_39), ch. 2
- [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_27), ch. 1
- [Defining unit testing, step by step](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_17), ch. 1
- [Integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_25), ch. 1
- [Interaction testing, mocks, and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_76), ch. 4

#### The Art of Unit Testing, 2nd ed.

- [Constrained frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev2sec1), ch. 6
- [Constrained and unconstrained frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev1sec1), ch. 6
- [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4
- [Refactoring your design to be more testable](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec4), ch. 3
- [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-10), ch. 10

#### osherove.com

- [TDD Kata 1 - String Calculator](https://osherove.com/tdd-kata-1)
- [Issues in breaking dependencies for unit testing](https://osherove.com/blog/2005/8/23/issues-in-breaking-dependencies-for-unit-testing.html)

[Previous lesson Capturing Mock Arguments](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/capturing-mock-arguments/) [Next lesson Faking Time](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/faking-time/)


---

## 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/