---
title: "Mocks, Stubs and Fakes"
url: "https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/mocks-stubs-and-fakes.md"
canonical: "https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/mocks-stubs-and-fakes/"
tags: []
author: "Roy Osherove"
description: "Lesson 6 of 15 in TDD and BDD in Ruby (Day 2 - Mocks, Stubs and Fakes), 18:09. 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/"
---

# Mocks, Stubs and Fakes

1. [Courses](https://courses.osherove.com/#courses)
2. [TDD and BDD in Ruby](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/)
3. Day 2 - Mocks, Stubs and Fakes

Lesson 6 of 15

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

Learn the difference between [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)"), [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 Fakes, and use a hand written approach to creating Mock Objects.

## In this lesson

Roy Osherove adds a requirement that the [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)") writes to a slow logger and, without a framework, replaces the logger in the spec with a [handwritten 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 class that has the same interface and saves the values for the assert. He defines 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)") as anything that looks like something else, 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)") as a fake that you assert against and 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)") as any other fake, and passes the fake in through [constructor injection](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_72 "Constructor injection (The Art of Unit Testing, 3rd ed., ch. 3)"). When a new requirement calls a web service if the logger raises an error, the fake web service becomes the mock and the fake logger a stub, and he advises [no more than a single mock object per test](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec5 "One mock per test (The Art of Unit Testing, 2nd ed., ch. 4)").

## Transcript

2,665 words

[\[00:02\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=2s) Let's start by talking about [mock objects](https://osherove.com/blog/2005/6/30/the-mock-objects-elevator-speech.html "The Mock Objects elevator speech (osherove.com)") [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)") and all the differences between them. If you remember that when we talked about what is a [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)"), do you remember what it means? >> Yeah. Okay. >> Yeah. What are the three [end results](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_18 "Entry points and exit points (The Art of Unit Testing, 3rd ed., ch. 1)") of a [unit of work](https://osherove.com/blog/2020/3/12/unit-testing-entry-points-and-exit-points "Unit Testing Entry and Exit Points (osherove.com)")? You remember >> [state change](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec7 "Testing results that are system state changes instead of return values (The Art of Unit Testing, 2nd ed., ch. 2)"). >> Okay. Okay. State based change, state based

[\[00:32\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=32s) A noticeable state change. Okay. >> Return value and >> [third party call](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_19 "Exit point types (The Art of Unit Testing, 3rd ed., ch. 1)"). >> Third party call. Which one of them would we try to use mock objects? >> Exactly. What about the others? Would we use any kind of mock objects there? >> I don't know. I don't know. Exactly. So that's what we'll learn. >> we'll learn about when to use [stubs and mocks](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_79 "The importance of differentiating between mocks and stubs (The Art of Unit Testing, 3rd ed., ch. 4)").

[\[01:05\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=65s) But let's talk about the [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)") that we've all learned to love. So we have a method called add numbers. And I want to add a feature to the method. I want the method to write a message to the logger. I have a slow logger class. And in that slow library class there is a call to a database or a web service. So it's definitely a big dependency for me kind of a problem.

[\[01:36\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=96s) If I if I if I wanted to I could probably write a test that calls add numbers and then checks the database or log file or something but that test will take a long time or it could be very complicated to achieve. But I do want to have this functionality and I do want to do it in a [test-driven](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)") way. So what do I do? Instead of having slow logger, I can replace it with something that looks like slow logger but that I have full control of. So in this case, slow logger might be built by a different team.

[\[02:07\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=127s) It might actually have a bug I don't have full control over that class or if I do it uses the file system which I do not have full control or it's going to be very slow. So I'm going to change to something that I could control. Once I have control of something, it is no longer called a dependency. It's just called a helper for us and we can use it in our test. So what I'm going to do is I'm not going to create anything

[\[02:38\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=158s) Using a framework yet. What we're going to do is we're going to create our own class called a fake logger. That's very easy to do in Ruby. You just create a class that has the same interface as slow logger. So we're talking about duck typing here. So if slow logger has a method write with that takes a string then fake logger will just have a method right takes a string. But the difference is that fake logger will reside in our spec folder. Okay. And hopefully even in the same file as our specs

[\[03:11\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=191s) And it won't actually do any logging. it will just save the value and then put it in some public attribute that we can then later assert on. Now it's important to have this technique because sometimes doing things the manual way can actually be simpler to read and maintain than using the framework. And it's also important to do this because it will help you understand how the other frameworks work or [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)") or mocking frameworks work.

[\[03:45\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=225s) So in this case what I'm actually creating is a mock object but notice that the word mock is nowhere near the the slide. So what is a mock object? It is a fake object that I assert against. Okay, it is something that looks like something else and I'm going to assert against it. So in my test, what I'm going to try and do is I'm going to create an instance of the fake logger. I'm going to create an instance of the string calculator.

[\[04:16\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=256s) I somehow have to get the string calculator to use the fake logger. Maybe I'll send it as a parameter to the initialize method. It's called a [constructor injection](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_72 "Constructor injection (The Art of Unit Testing, 3rd ed., ch. 3)"). Maybe I can put it as a dependency, as an attribute. That's called property injection. I have to get them to play together and then I will call add numbers on the string calculator but I will assert against fake logger dot some public attribute that I have added to it.

[\[04:46\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=286s) So I have full control over everything in this test and so I can say that it's a unit test. If I was using the real slow logger, I would call it an [integration test](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)") because it would use either the network or the file system or database or something that I do not have control over. For example, threads. Threads are considered integration testing because you do not have control over them. They make the test take longer. You have to start killing them and manipulating them and forking and joining and all this weird stuff.

[\[05:16\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=316s) So, it complicates the test. It's also a type of dependency. So fake logger is going to be a mock object. So let's see how that works. Okay, here we can see an example of making the logger a dependency on the string calculator. So I gone ahead and made a special class just for demos called string calculator one depth because we're going to have two dependencies later.

[\[05:48\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=348s) So this is just one dependency and basically what we want to have is this. I've gone ahead and added a the logger variable instantiation from the initializer here. And what I want to do is to notify the logger the add numbers. And this is what notify logger does. So, I'd like to be able to test this. And to be able to do that, what I've gone ahead and done

[\[06:22\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=382s) Is to create a fake logger. I call it a fake slow logger. What did the slow logger look like? This is the slow logger. See, we have a lib slow logger. And imagine that here we would have very slow this. So use the sheet C# sometimes this logger is very slow.

[\[06:53\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=413s) Okay. So we can't use this or maybe it's being controlled by a different team. Either way in my specs I've created my own fake slow logger. Okay, so fake slow logger has an attribute called numbers and we'll disregard will throw for now and we implement the method write

[\[07:24\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=444s) And we just save the numbers. So, this is the most simplest way I can think of of creating a fake slow logger. And I'm not using a framework yet because I want everyone to learn how to use [handwritten fakes](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)"). Now, notice I'm not calling it not calling it [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)") slow logger. I'm calling it fake slow. And there's a good reason. I might want to reuse it. And a fake object is anything that looks like anything else.

[\[07:56\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=476s) Based on how it's used, it's either a mock or a stub. I'll explain that this time I'm going to be using it as a mock. But in the next example, I'm going to be using this exact class as a stub. So here I have the adding feature and in the context of a logger attached it calls the logger. So here we just instantiate logger with the fake slow logger new instantiate the string calculator one dependency

[\[08:28\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=508s) And call the add method on it. Now then all I have to do is to go to this special attribute I've created on the fake logger called numbers over here. Now because this is class is part of our test project we have full control over it. We can add whatever things we want to and obviously we don't implement the real write method.

[\[09:01\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=541s) We just override it and create our own thing that just does nothing and just save the values saves the values. This way if the value here is actually got one then we know that string calculator logger was actually called. So again to do that I had to add a constructor argument to the string calculator one dependency

[\[09:34\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=574s) Which is over here. So I added one logger the logger here. I'm saving it and this is called constructure constructor injection. This is very important technique. It makes the dependencies very very explicit and easy to document. So in this case logger is a mock object.

[\[10:04\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=604s) But let's look at a more complicated scenario now. What if we have a new requirement that says now you have two dependencies. One of them is a slow logger and another is a web service. And as a system administrator, I would like to know when slow logger fails. I want to be notified in special web service when that happens. So now what I would want to do is to somehow fake make slow logger raise an error in my test

[\[10:35\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=635s) And then if an error is caught in the string calculator from slow logger then web service should be called with the error details. So now I have this interesting dependencies one of them should raise an error the other one one of them should be called. So in this case, which one is the mock object? What would I assert against in this case?

[\[11:06\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=666s) I would assert against the web service. So what is a web service? No, it's a mock object. If I assert against it, I'll I'll create a fake logger, but I'll also create a fake web service. And then I'll assert against the fake web service, and that would make it a mock. So what about the fake law in this case? What would I assert against it? No, I don't need to assert against it. I have a test that proves it gets false. So I don't need to assert against it in a new test. But if I don't assert against it, it becomes a stub.

[\[11:39\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=699s) That's it. So one of them is a mock and one of them is a stub. Why is it important to differentiate between a mock object and a stub? Because as a rule of thumb, you should have [no more than a single mock object per test](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-5 "Having more than one mock per test (The Art of Unit Testing, 3rd ed., ch. 5)") perspective. Because a mock object represents an end result, right? It's a call to a third party. If you're if you have multiple mock objects, you're testing in the same test in the same spec that you're calling multiple third parties.

[\[12:11\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=731s) Each one of them should be in a separate test because each test is a feature. Even worse, if you have multiple mock objects and one of the calls to one of them fails, all the calls, all the asserts below that line will never execute. So you won't have as much information. So separating into multiple specs is also a good idea because you'll get more information about everything that passed and everything that failed. Okay, so mock objects are usually one per test, no more.

[\[12:48\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=768s) Sorry. >> Yeah, it's based on the end result. So if I if I have a test for a value based test then I'm asserting that I got back a value I would not have a mock object in the same test because there are two different end results two different concerns should be in two different tests because if one of them fails the other one will never execute and also it makes the [test name](https://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html "Naming standards for unit tests (osherove.com)") less readable because testing two things at once. And if I have a statebased test, I wouldn't have a mock object because it's another form of end result.

[\[13:20\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=800s) So, never mix multiple end results testing in the same test. A mock object is a form of end result testing. End result testing. Okay. Okay. So, how do I now this time since I have the two dependencies, I need to do two things. First, I have to make the create a fake logger and somehow make simulate an exception. So what I've done is I've gone ahead and if we look at the fake logger here,

[\[13:51\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=831s) I've added a will throw accessor and a simple line called raise whatever is in will throw if will throw is not. This is important because then my test can do something simple like this. context given a throwing logger in a web service it calls the web service. So I'm creating the fake logger

[\[14:22\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=862s) And I'm saying logger will throw the fake error and now I'm going gone ahead and created a fake web service class that looks like this. And this is basically the same interface that the web service has. But again, instead of the write method, I just overwrite it and do whatever I want, which is just to save the value into an accessor accessor. Then I can use that accessor in my tests

[\[14:56\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=896s) And basically say web service numbers should equals fake error. And when I instantiate, I've refactored string calculator one dependencies to now have two dependencies. And those two dependencies are in the initializer. So I send in the logger and the web service and I call add. And then I check the web service. So again, I've added a new functionality to the fake logger class where I can tell it to throw different things.

[\[15:30\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=930s) I'm still saving the value, but notice that in this case, the logger is no longer a mock object because I'm not asserting anything against it. I'm only asserting against the web service. So a mock object is anything that's fake and you can you assert against it. So that means that the web service is the mock object and that makes the logger a stub. So everything that you don't assert against and it's fake, that's called a stub.

[\[16:00\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=960s) Now why is it important to differentiate between them again? It's because usually you want to have only a single mock object in your test because a mock object is testing one end result. So if you have multiple mock objects, you're basically testing multiple things in the same specification and if one of them fails, the line after that will never execute. So you won't know if the second one is actually working. That's why you want to separate for each single test or spec to have no more than a single mock object.

[\[16:34\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=994s) But you can have multiple steps. You can have multiple dependencies, but you're only checking that one of them got called at any specific time because each call to a third party dependency is literally its own feature. This is the exercise we're going to do in a second. But this is the terminology. So we have fakes. And if you verify against it, it's a mock otherwise it's a stub. Now there is a terminology in a book called xunit test patterns which is a really good reference.

[\[17:08\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=1028s) But that book has a lot of terminology on different types of fake objects and each one of them does things just a little bit differently. And I find that this is actually very confusing for a lot of people and there is no reason to differentiate so much. So I would only differentiate between a stub and a mock object because you need to know that you only have one of those and you can have many stubs if you want to. So I just use a very very simple terminology that everything is a fake and based on how you use it, it's either a mock or a stub.

[\[17:40\]](https://www.youtube.com/watch?v=0JTKzxKd8pk&t=1060s) So a mock is an example of a fake. Stub is an example of fake. If you assert against it, that fake is also a mock object. Okay. Okay. So, what we're going to do now is we're going to go through this exercise. Okay. For you and for the viewers at home, I want you to go through this

## Related

- [The importance of differentiating between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_79) · The Art of Unit Testing, 3rd ed., ch. 4

    The 3rd edition's section on why to tell mocks from stubs, the distinction between a fake you assert against and any other fake taught here.

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

    The 2nd edition's handwritten mock example, the same no-framework approach used for the fake logger.

- [Using a mock and a stub together](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec4) · The Art of Unit Testing, 2nd ed., ch. 4

    Section on using a mock and a stub together, as when the fake web service becomes the mock and the fake logger a stub.

- [Constructor injection](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_72) · The Art of Unit Testing, 3rd ed., ch. 3

    Section on constructor injection, how the fake logger is passed into the string calculator.

- [Multiple mocks, asserts, and hidden results](https://osherove.com/blog/2011/2/9/multiple-mocks-asserts-and-hidden-results.html) · osherove.com

    Roy's reply on multiple mocks and hidden results, the reasoning behind the advice of no more than one mock object per test.

### Also linked in this lesson

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

- [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
- [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
- [Entry points and exit points](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_18), ch. 1
- [Exit point types](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_19), ch. 1
- [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_27), ch. 1
- [Defining isolation frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-5#sigil_toc_id_99), ch. 5
- [Integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_25), ch. 1
- [Having more than one mock per test](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-5), ch. 5

#### 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
- [One mock per test](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec5), ch. 4
- [Interaction testing using mock objects](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4), ch. 4
- [Introducing stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec1), ch. 3
- [Testing results that are system state changes instead of return values](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec7), ch. 2
- [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

- [TDD Kata 1 - String Calculator](https://osherove.com/tdd-kata-1)
- [The Mock Objects elevator speech](https://osherove.com/blog/2005/6/30/the-mock-objects-elevator-speech.html)
- [Unit Testing Entry and Exit Points](https://osherove.com/blog/2020/3/12/unit-testing-entry-points-and-exit-points)
- [Naming standards for unit tests](https://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html)

[Previous lesson Common Questions and Answers about Test Driven Development](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/common-questions-and-answers-about-test-driven-development/) [Next lesson Using Bogus](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/using-bogus/)


---

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