---
title: "Faking Futures"
url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/faking-futures.md"
canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/faking-futures/"
tags: []
author: "Roy Osherove"
description: "Lesson 16 of 21 in The Art of Unit Testing and TDD in Java (Day 3), 2:41. 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/"
---

# Faking Futures

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 16 of 21

Duration: 2:41 [Watch on YouTube](https://www.youtube.com/watch?v=A5k38-k__ng)

How do you deal with objects being creating directly inside [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)")? We can refactor that!

## In this lesson

Roy Osherove discusses an exercise with a login manager that creates a new slow logger, where the test has to prove that the logger's write method is called. He compares extracting a protected method that returns the slow logger, which needs a [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)") subclass of it, with extracting the whole call into a protected method, which he usually prefers as simpler.

## Transcript

376 words

[\[00:03\]](https://www.youtube.com/watch?v=A5k38-k__ng&t=3s) So this is let's talk for a second about the requirement about login manager with future. Now login manager with future you you have a call to new slow logger and the requirement is that you prove that it calls the new slow logger with the method write because this is [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)"). Now we have two choices when it comes to new. We can either refactor just this part of the call or we can refactor the whole call.

[\[00:34\]](https://www.youtube.com/watch?v=A5k38-k__ng&t=34s) If we refactor just the call to slow logger to create the new one we set a method called get slow logger and make it protected. What happens now? We have to return something that looks like a slow logger. In our test, we'd have to create a class that inherits from slow logger, overrides whatever is needed, and then returns that. That's possible, but that's more complicated. We also will inherit anything from slow logger that we don't override.

[\[01:04\]](https://www.youtube.com/watch?v=A5k38-k__ng&t=64s) That could mean that maybe it uses something underneath we don't control. So, it's more complicated to do this than to say protected void. or sorry let's undo this whole thing and say extract this whole line say call new logger make that protect it and make this a variable

[\[01:40\]](https://www.youtube.com/watch?v=A5k38-k__ng&t=100s) So here we might say text like this. Now, this is very much like what we did before with static logger. It's a much simpler way to check that something was called. So, we can either choose to fake one level below and return the object or we can choose to just call the object in the [simplest way possible](https://osherove.com/blog/2010/1/6/tdd-4-questions-that-will-help-you-create-the-simplest-thing.html "TDD: 4 questions that will help you create the simplest thing that could possibly work (osherove.com)") and prove that that happened. I usually choose this way

[\[02:11\]](https://www.youtube.com/watch?v=A5k38-k__ng&t=131s) Rather than return a slow log or other unless I really have no choice and I only have no choice when I need 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)") to be called and I have no way to inject the mock object. For example, if I need to check that not a static logger was called but that a new slow logger was called. Right? This is the only way I either have to do this or I have to return an instance. And this this is actually the the simplest way that I know how to do it.

## 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, comparing extract-and-override choices like these two.

- [Issues in breaking dependencies for unit testing](https://osherove.com/blog/2005/8/23/issues-in-breaking-dependencies-for-unit-testing.html) · osherove.com

    Roy's post on ways to break dependencies on an existing class in legacy code, like the newed-up slow logger.

- [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

    Roy's consulting notes on testing a hard-to-test method in legacy code, using refactorings like extract and override.

### Also linked in this lesson

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

- [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12), ch. 12
- [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.

- [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4
- [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-10), ch. 10

#### osherove.com

- [TDD: 4 questions that will help you create the simplest thing that could possibly work](https://osherove.com/blog/2010/1/6/tdd-4-questions-that-will-help-you-create-the-simplest-thing.html)

[Previous lesson Faking Time](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/faking-time/) [Next lesson Unconstrained Isolation Frameworks](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/unconstrained-isolation-frameworks/)


---

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