---
title: "Introduction to Hand Written Fakes, Mocks and Stubs"
url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-master-class-in-net/introduction-to-hand-written-fakes-mocks-and-stubs.md"
canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-master-class-in-net/introduction-to-hand-written-fakes-mocks-and-stubs/"
tags: []
author: "Roy Osherove"
description: "Lesson 4 of 14 in The Art of Unit Testing & TDD Master Class in .NET (Fakes, Mocks and Stubs), 7:18. 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/"
---

# Introduction to Hand Written Fakes, Mocks and Stubs

1. [Courses](https://courses.osherove.com/#courses)
2. [The Art of Unit Testing & TDD Master Class in .NET](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-master-class-in-net/)
3. Fakes, Mocks and Stubs

Lesson 4 of 14

Duration: 7:18 [Watch on YouTube](https://www.youtube.com/watch?v=l9X2kunieG8)

Roy Introduces the idea of [mocks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4 "Interaction testing using mock objects (The Art of Unit Testing, 2nd ed., ch. 4)"), [fakes](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec2 "Dynamically creating a fake object (The Art of Unit Testing, 2nd ed., ch. 5)") and [stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec1 "Introducing stubs (The Art of Unit Testing, 2nd ed., ch. 3)") and shows how to [hand write them](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec7 "The problems with handwritten mocks and stubs (The Art of Unit Testing, 2nd ed., ch. 4)"), and when it makes sense to hand write them.

## In this lesson

With a login manager whose save method must also call a logger written by another team, Roy Osherove introduces [an ILogger 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)") so a [hand-written fake](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec3 "A simple handwritten mock example (The Art of Unit Testing, 2nd ed., ch. 4)") logger can replace the real one. 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)") the test asserts against is 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)"), one it does not assert against is a [stub](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_62 "Reasons to use stubs (The Art of Unit Testing, 3rd ed., ch. 3)"), and the same class can serve as either. He also explains that injecting the fake through a constructor, rather than a property, tells the user of the API the dependency is not optional.

## Transcript

1,023 words

[\[00:25\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=25s) So now that we've done a simple replacement of an object, let's talk about the idea of [mock objects](https://osherove.com/blog/2005/6/30/the-mock-objects-elevator-speech.html "The Mock Objects elevator speech (osherove.com)"). and [stubs](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_62 "Reasons to use stubs (The Art of Unit Testing, 3rd ed., ch. 3)"). let's talk about a more interesting case where where things are not built in where we actually have to build a UI 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)") object. So imagine that you have a class called login manager.

[\[00:56\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=56s) Login manager already uses a logger class and there is a method called save. Now the point of the save method is to to save an object. But if an object has a property that's something that is too big for example then what we should do is we should also log the fact that there was an object that was saved that was too large.

[\[01:28\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=88s) So the requirement is that there are actually two requirements save and also write to the logger if there is something that happens or call the logger. Now let's assume that the logger is written by a different team. So it's actually not under our control or maybe it's actually not even done yet. Maybe it was written to maybe the code was written but it was not it's not finished yet.

[\[01:58\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=118s) So every time we want to actually call the logger we get an exception. So now we actually have an interesting situation where our team is depending on a different team. the team that writes the logger and we actually have to wait for them to finish the job. Or maybe the logger takes such a long time that we don't want to use it in our real tests. So instead of using the real logger, we can replace it with something else.

[\[02:29\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=149s) We can introduce a new interface into the system. to be able to replace something in a static language like C#, it has to inherit from some from the same object or implement the same interface. So we can introduce [an ILogger 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)"). So now instead of logger, we create a new interface and it only has one method which is write just like logger has. But now in the constructor for login manager, there's an ILogger instead of a logger. So it doesn't care which logger it uses.

[\[03:01\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=181s) And this ILogger is actually part of the production code. It's not part of the tests. But now because I have that interface in my tests, I can create a new class that I create by hand called fake logger. And the nice thing about fake logger is that it's actually part of the test project. So it implements the same interface, but because it's in the test project, it doesn't have to do anything. I just implement the methods and they're empty.

[\[03:33\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=213s) They're not really doing anything. In fact, I can also override the methods and save the values that were sent in. Okay, so I can save the values and put them in, let's say, a public field or something like that. And in my test, I can use a fake logger instead of a real one. send it to the constructor of the login manager. And now in my test, I'll create the login manager, send it to the the fake logger, call save, and then assert against the fake logger that some field contains a string or something like that.

[\[04:10\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=250s) Just like I did with the string builder in the previous exercise, this time there is no string builder. There is no built-in API. So I created my own API for this, something that I have full control over. So when we have a fake object and I specifically call this class a fake logger not a mock logger or sub or anything like that it's a fake logger because it can replace something but when I have a fake object that I also assert against

[\[04:41\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=281s) Then that's called a mock object. The concept of a mock object is that there's something fake, not real in the system. But I'm also but it also decides whether my test failed or not. So if it has the power to break my test and decide that that my test failed, then it's a mock object. But if it's a fake something and I'm not asserting against it, then it's just a stub. So there's the idea of a fake and it's either a stub or a mock based on how I use it.

[\[05:13\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=313s) And if I keep this class clean enough, I can reuse it to be a mock in one test and then the same class can be used as a stub in another test. That's a that's that's important because we don't want to have 15 different classes in our test projects for for a single type of object. So let's see that. This is a demo of a class called login manager. Now I called it login manager with mock but usually the word mock will not be part of production code just for demos.

[\[05:55\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=355s) Now I already went ahead and created the interface for ILogger here. So there's an interface for ILogger. It has just one method called write. There's also a logger exception but we don't care about that for for now. We have a constructor and here I made a design decision that I can send in the ILogger through a constructor. But I could also have chosen not to add a constructor parameter. I could have chosen to add a property or a method that takes in and sets up a private field.

[\[06:28\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=388s) So what's the difference? What when would I choose to use a constructor and when would I choose to use something else to inject that fake object? Any ideas? Why would I use a constructor? >> What's the difference between a constructor and a property? >> You have to put it there. >> Yeah, it's not optional. Good. I have to use the constructor. So when I put an argument as a constructor, I'm actually telling the user of my API, this is not optional.

[\[07:01\]](https://www.youtube.com/watch?v=l9X2kunieG8&t=421s) You have to provide this. That's an important design decision because it means it can never be null. For example,

## Related

- [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2) · The Art of Unit Testing, 2nd ed., ch. 4

    The 2nd edition's section on the difference between mocks and stubs, the same line drawn with the fake logger.

- [A simple handwritten mock example](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec3) · The Art of Unit Testing, 2nd ed., ch. 4

    A simple handwritten mock example from the 2nd edition, matching the hand-written fake logger built here.

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

    The 2nd edition's section on refactoring a design for testability, including injecting fakes through the constructor.

- [Mocks and Stubs - The difference is in the flow of information](https://osherove.com/blog/2007/9/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.html) · osherove.com

    Roy's short classroom explanation of mocks versus stubs as a difference in the flow of information.

### Also linked in this lesson

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

- [Extracting a common interface](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_74), ch. 3
- [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
- [Reasons to use stubs](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_62), ch. 3

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

- [Interaction testing using mock objects](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4), ch. 4
- [Dynamically creating a fake object](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec2), ch. 5
- [Introducing stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec1), ch. 3
- [The problems with handwritten mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec7), ch. 4

#### osherove.com

- [The Mock Objects elevator speech](https://osherove.com/blog/2005/6/30/the-mock-objects-elevator-speech.html)

[Previous lesson Test Driving a Console Application Using String Calculator](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-master-class-in-net/test-driving-a-console-application-using-string-calculator/) [Next lesson Isolation Frameworks](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-master-class-in-net/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/