--- title: "Common Questions and Answers about Test Driven Development" url: "https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/common-questions-and-answers-about-test-driven-development.md" canonical: "https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/common-questions-and-answers-about-test-driven-development/" tags: [] author: "Roy Osherove" description: "Lesson 5 of 15 in TDD and BDD in Ruby (Day 1 - Basic Building Blocks), 26:25. 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/" --- # Common Questions and Answers about Test Driven Development 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 1 - Basic Building Blocks Lesson 5 of 15 Duration: 26:25 [Watch on YouTube](https://www.youtube.com/watch?v=6lUpQAV8dn4) Common questions everyone asks when they see [test driven development](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec6 "Test-driven development (The Art of Unit Testing, 2nd ed., ch. 1)") for the first time: Should I write many failing tests at the same time? what's the point of making the test fail first? these and more will be answered. ## In this lesson Roy Osherove answers why tests are written before the code: [to test the test](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2 "Testing the test (The Art of Unit Testing, 3rd ed., ch. 2)"), to think about the problem before the solution, to be the first user of the API, and because there is never time to write them afterwards. He explains why he keeps only a single failing test at a time and uses [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)") as a development technique for moving fast that usually tests the happy path rather than every invalid value. He also presents [numbers from two teams](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-11 "Is there proof that unit testing helps? (The Art of Unit Testing, 3rd ed., ch. 11)") at a company he consulted for, where the TDD team released two days earlier, in 24 days instead of 26, with 90% fewer bugs found in production. ## Transcript 4,123 words [\[00:03\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=3s) So let's talk about some common questions that people usually get when they do [test driven development](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_29 "Three core skills needed for successful TDD (The Art of Unit Testing, 3rd ed., ch. 1)"). What so let me first ask you why do you write the test before the code? What's the point now that you've done it? What's the point >> to kind of create your mind to create in your mind the code that you want to have? Yeah, that's one point. Why else [\[00:43\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=43s) >> you see that it fails first? Okay. And then what is the point of failing first? [test the test](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2 "Testing the test (The Art of Unit Testing, 3rd ed., ch. 2)") in a way. Okay. So here's I I there's something else and one of the things that people don't realize is that writing the test first is also a very good excuse for thinking about the problem before thinking about the solution. [\[01:16\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=76s) For example, if you canot give a good name to the test, maybe you don't understand the problem. So, finding a good name for a test is an example of thinking about the problem. Thinking about the design and the usability of the API, that's something that you mentioned that you think about the code that you would like to have. But here's the point. You think about your code now as a user of the code. Okay? Imagine that you want to create a method for division. [\[01:48\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=108s) If you start with just the division method directly, what you end up with is you just write a method and you don't care about the parameters, the ordering and things like that. But if you write the test first, you write the test and you realize maybe the name is not as good as it could be or the order of parameters suddenly matters. So it's more usable. So when you write test first, your tests become another user to your APIs. that makes your API more usable. [\[02:21\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=141s) And of course, there's never time to write the test after. So that's a good reason to write it before. >> Nobody ever has time. So that's one of the best ways that I know to to start early to just get the test before everything. And it's kind of like when I talked about the skeleton, the [shipping skeleton](https://pipelinedriven.org/article/2014/3/2/pattern-shipping-skeleton "Pattern: Shipping Skeleton (pipelinedriven.org)"). Nobody ever has time, but you have to set up the servers and all that stuff at the end when everyone is stressed. So if you get over with the beginning, everyone is much less stressed after. So you get all this things you hate the beginning. Just get it out of the way. [\[02:57\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=177s) And one of the things that I've noticed is that if I write my tests after, I write less tests. I do test some of the things, but some of the things I just don't bother testing because I'm not objective about my thought. which is exactly the point. But by writing test first, you are being more objective about the code because you know the code is not working. When you write the test after you know the code is working. So you're testing to prove that it works when actual good testing is when you prove that something doesn't work. [\[03:35\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=215s) So why make it fail first? We started touching on on that. But the first thing that I like about having a test that fails before it passes is that we're testing the test itself. Another thing is that I'm going to make this black for a second just so you don't get the peak. >> But one of the things that I like as well is that you write the test and you are seeing the the problem for the first time from the point of view of a user. [\[04:08\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=248s) That's very objective but I forgot what I was going to say. Oh yeah, you define a small problem and then and then you solve it. So so you have a a failing test and now you just need to make that one test pass. You don't you don't write many tests at the same time fail. Write one test fails and then you have a very simple problem solved. If you don't have any tests, you have a very big problem solved. So you might be very scary to start solving it. If you have that you just solve it to the [simplest way](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)") you possible. [\[04:39\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=279s) It's always easy to take one step towards the solution than to take a hund especially if it's a very complicated solution. So I find that if I have a very tough problem ahead of me, starting with a very simple test really gets me going much much faster. Instead of I just instead of just thinking for a week just about the problem and how to approach it, I should start with the test how to approach the API and then slowly add more and more and more and more features. And if you can't write the test, the failing test, maybe you don't understand the problem. [\[05:14\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=314s) That's a that's something that that happens a lot is that when you first write test for your code, what you what happens at the beginning is that it takes a long time to write the first few tests. And the reason is is because you're trying to understand the structure of your code and where to test it and what to [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)") and what to change and what is supposed to fail and how to check that it fails. What does it mean to fail for this test? What do you assert against? How do you what things do you need to change the system to get everything going? [\[05:44\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=344s) So the first few tests really make you understand the system in the problem space much better. And if you don't have a failing test or if you start with a failing test and it doesn't fail, what does that mean? Means you have a bug in the test, right? Or you're testing the wrong thing. And that happens as well. We write a test and we think it's the most amazing test in the world, but because we wrote the test first, it doesn't fail. And we know it definitely should fail because the feature doesn't work. [\[06:18\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=378s) So now we start to look for what the hell is going on. We look for bugs in the test. We look maybe the we're using the code wrong. Maybe the code is actually working. We don't know. Either way, we are not moving forward until we know what it means to fail. Maybe we don't understand the whole thing. Another common question is why do we want to solve things as simply as possible? I talked about this before. Let's see if you remember. Why is simplicity important? [\[06:57\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=417s) We don't solve like run for a general solution for sol >> you get more tests because you solve things more simply because you force yourself through because you say I don't like this code but I cannot change it. So I write another test to prove what's wrong with it. Yes, that's one reason. So simplicity do does bring more tests. But what else? [\[07:37\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=457s) >> Yes, it makes the code simpler. I fully agree. Simplicity is simpler than not having simplicity. So one of the things that you might realize is that when you think about simplicity and you try to get it which is not a simple thing, but once you do achieve it, you you might end up with code that is much simpler than you thought you would end up because we're used to solving things in a very generic way, but sometimes than less generic way, works just as good, and it and it works just as well, and it's just as easy to change in the future. [\[08:08\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=488s) So, we so we can we can save that extra time and extra effort for other things. You do get better [code coverage](https://osherove.com/blog/2005/4/3/test-coverage-and-testing-angles.html "Test Coverage and testing angles (osherove.com)") if you if you write the test the code in a simple way because it forces you to write tests for any piece of code that actually gets written. So if you have a loop there has to be a good reason for that loop. Otherwise don't write a loop. Have a test that says yeah you might have more than a few. You can't know how many objects you have. [\[08:41\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=521s) Once you have those kinds of tests, that forces you to write loops. You don't need to have a split unless you have a test that says aha, you can't always assume that you know how long things are in a string. But the split has a reason to exist. So there's a there is a test that will fail if we remove the split. a test that will fail. We remove the loop or we don't have the same functionality as looping [\[09:13\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=553s) Refactoring. So, what's the definition of refactoring? Does anybody know? >> Reorganize the code without changing any of the functionality. >> Yes, exactly. That's the exact definition. Refactoring is changing your code without changing the functionality. So if you ever renamed the method even manually that's refactoring. If you ever took a long method and you split it up into many small methods that's refactoring as well. [\[09:45\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=585s) It could be anything that makes the code more reusable or less reusable. Refactoring is not always if you don't do refactoring well you can actually do harm. But if but the point is that you do not change functionality because if you do change functionality there has to be a test that proves that that functionality is missing. But why do we do refactoring in the process of TDD? TDD is red green refactoring. Start with the failing test. [\[10:16\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=616s) We make it pass as simply as possible and then we refactor. Why should we do the refactoring part? Just because someone says you have to do it doesn't mean you should do it >> simpler. >> To make the code simpler to make it more maintainable. It hopefully it's simpler because you made it pass in the simplest way possible but it could be less readable less maintainable. So it's about maybe keeping your sanity because you solve things in the simplest way possible [\[10:48\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=648s) But now you you dislike the way the code ends up. For example, you have duplicated code because that was the simplest way. So now the code passes now maybe you can remove the duplication. So the refactoring step is very important. Because without the refactoring you end up with a lot of code that works but it looks horrible and it reads horrible and it's hard to maintain. So as long as you don't change the functionality, make it better every time. [\[11:23\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=683s) Now the point of [unit tests](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)") is to actually one of the things that many people feel is that the point of tests is to to have better quality when you do test development. Probably you do as well. A lot of people say I do test driven development because I want better quality. Test driven development at at its core at the core practice is not used for quality because when you when I do TDD I don't necessarily test everything with my brain. [\[12:00\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=720s) When I do TDD it's a development technique. It's a way that allows me to go very very fast. So if you think about it, TDD is I write tests for the things that are the most important and I have a backbone of things. But when you do unit testing, there are some things you don't test, right? For example, integrations between classes, fake classes and things like that. But you don't usually do [integration testing](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)") when you do unit testing. [\[12:31\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=751s) You just testing the logic of things. You still have to do integration testing to the system works. So I use TDD to to drive functionality very very quickly. And that's one of the reasons that when I do test room development, I don't actually try to test all the things that could go wrong. I usually test happy path. For example, in the [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)"), I would check all the valid values, but I wouldn't check all the invalid values unless I specifically had a requirement for it. [\[13:03\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=783s) So the fact that I can do one zero, one or two numbers doesn't mean that I will add a test for three numbers fails or if I send in the letter A it fails. Why wouldn't I do that? Because the point of TD is to drive forward to have more and more functionality every minute or every day that you had before that's covered by a test. It's not to know that everything that's possibly could go wrong is is handled because the point is to to drive towards demo and feedback as quickly as possible. [\[13:40\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=820s) So as an example, if you if you ever had to to to if you wanted to, you could write many tests for all the invalid values that string calculator could do. You could spend a whole day just writing tests for string calculator. all the things that you shouldn't receive. Agreed? But then at the end of the day, your manager would come to you and say, "Hey, what's up? How's it going?" And you say, "Well, it's not working yet, but it handles all the invalid values beautifully." And that's not the point. [\[14:15\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=855s) The point is that you want to show a demo at the end of the day with actual functionality that works. You get feedback that you're building and the right thing. You can add later all the invalid values you want. But TDD is about building the spine of the application, all the good stuff and then on that you add more things. But first of all, you want to make sure you're building the right thing. So TDD is not about the full quality of the product. It is a development activity that also has the benefits of having code coverage and tests and regression testing for the things that you did. [\[14:53\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=893s) But the main point is to drive forward with the idea that this is what I'm trying to do. This is what I'm trying to achieve. Show a demo. Move forward. Move forward. It's about incremental change. So every test is like a mini iteration. And that's the the point of working incrementally that every test is a mini iteration just like every iteration is a mini release of the product. So if every I can show a demo of something that worked. [\[15:26\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=926s) Right. Yesterday when we did ser calculator, it took us maybe 15 minutes or maybe five minutes to get to a situation where we were able to handle a string calculator that handles empty strings. A string calculator that handles a single number. It did not know how to handle two numbers yet or multiple numbers or negative numbers. But it had incremental features. I could actually demo two of the features. Send in an empty number, see what happened. [\[15:57\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=957s) Send in a single number, see what happen. I could demo in the middle of the day yesterday, string out calculator if I wanted to. That was the point is that every few minutes I have a small increment of actual working code. So then what happens at the end of two weeks of iteration? It's just another day because as far as I'm concerned, if I have the the backbone of the release process and I check in, I have continuous deployment, then then release day is just another day because I've been releasing 50 times last week. [\[16:29\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=989s) And that was kind of the point that the tests are incremental iterations. They're a way of thinking about problems in incremental ways. now there is this there was a study that was done and I I think you can read about it in the book called the inmates are running the asylum by the person who invented visual basic and in that book he talks about the fact that 60% of the features that you build probably won't be used. [\[17:02\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1022s) You look at Office at Microsoft Word, how many of the features in Word are you actually using? Probably 10% maybe like your brain using 10% of your brain. But that's kind of the point. If if if you know that people are going to use maybe half of the things that you build, don't build half of the things. Work incrementally only towards what you know is fully required. Unless someone actually asks you to add the feature, don't add the feature. If you don't need to an initializer, don't add an initializer. [\[17:35\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1055s) If you don't need to add another method or an overload of a method, don't do it. That's called not planning not overplanning for the future. When people will need it, it will be important enough. It will be high priority when we do it. And that will keep us on track, focused on just the things we actually need. Now a question that keeps coming up is why not write many tests at once that fail. And actually I used to actually do this. [\[18:05\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1085s) I used to I used to go to a team and and give them teach them that they can write some tests for a data layer class and then implement all the failing tests for an abstract class test basic base tests. And then what happened was that you had this huge chunk of implementation to work with and it and you spend two days working red just see red in front of your your eyes. [\[18:36\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1116s) Psychologically that's not a good feeling. We what we want is to feel good steady progress of small wins. That's why we want to have only a single test at each time because that that that gives us a positive loop instead of a negative one. When you have red for in your eyes for two days, that's that's going to make you less happy at work. It's going to make you less productive. It's going to make you everything that you don't want to be [\[19:08\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1148s) Annoyed, frustrated, over overarchitecting because you say, "Okay, if I do just these two lines, I'm going to solve four test at the same time, but the there are big chances that you're going to add more features than you are actually being asked to do. By having a single test, you're focusing on just the things that you absolutely need. So, they're less risk. I want to talk to you about some numbers. These are numbers that that from a company that I consulted for a few years ago where we had two teams. [\[19:44\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1184s) The team on the right was a team that had gone through test during development course a couple of months before and they were doing TD unit testing. The team on the left was not it was a company where the teams were basically adapting an application to different customers. was relating to really cellular stuff. And what was interesting is that both of these teams were willing to do an experiment where they had kind of the same project for two different customers, almost the same thing, [\[20:22\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1222s) And management really wanted to see whether they made sense after all that time they spent. So the team on the right implemented the same tasks with with test rate development and the team on the left didn't they didn't do any testing at all. Now the numbers at the bottom are the end results of what what actually happened over about a 3we period. [\[20:55\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1255s) So this is a big company you have to take that into account. So we had double amount of implementation on the first one for TDD. It took 100% more time to do the same features with test development. And that actually makes sense. It could take even a bit more because you write a test for every piece of piece of code. Your test might end up to be 60% of your code if you do TDD. So you definitely write more code [\[21:27\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1287s) And takes more time. Now as time goes by the more effective you are you become more effective as time goes by. You learn new things and things go a bit faster. But they did not have a lot of experience. So took them double. So the team on the left got about half of the time to the first steps and then it went into a QA cycle where they would test and fix bugs and test and fix bugs and ended up with three days difference even though they started with a 7-day difference. [\[22:00\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1320s) And the reason was is that they obviously found less bugs but when they did find bugs it was easier for them to see where the bugs are, stick to them and see that they didn't break anything else by fixing So they the amount of returning butts or propping up butts while fixing something else was much lower. So the big question was was it worth it the extra 3 days? [\[22:31\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1351s) Was it worth it to have the extra three days for that other team? So here's what we ended up getting. The amount of bugs found in production for the the TDD was 90% lower. The developers felt that there was a much better design to the code. The customer was happier because they had less bugs. The coders were happier and it cost them three days more. I don't know a single manager that would say, "Yeah, I don't want that." [\[23:02\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1382s) The problem is that when you look at TDD, you don't look at the bottom numbers because you don't have them yet. It takes time to get those numbers. Now I want to confess to you something. I absolutely lied about what actually happened there. What actually happened was this in between the implementation they had integration phases because there were multiple teams and modules. So there were there were actually integration phase with different modules that took much longer for the team without TDD than the team with TD took them two days versus seven days. [\[23:40\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1420s) So what ended up happening is that the team that did test driven development actually released the code to the customer two days earlier in 24 days versus 26. And one of the reasons that happened is that the integration week you see on the left seven days is what's called inte integration week hell or like initiation week for the coders there because it was a week of just hell pure hell of integrating with all the other projects and things were failing and all the all the interactions were failing and you would have to debug into the night just to see what the hell was going on. [\[24:26\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1466s) And that happened to be much less frightening for the team that did TDD and they were really surprised. But what one of the biggest factors is because they had unit tests and some integration tests when they did find bugs in the integration with other modules they could discount those bugs as either integration or unit tests because they had unit tests that cover the same scenarios. So if I called module X and I got an error and I knew that I already have a unit test that covers the exact same scenario, [\[24:59\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1499s) I would know that the problem is not in the logic, but it is indeed in the integration and the configuration of the modules. So it would be faster for me to go and fix the problem. So less debugging time. So again, it took them less time to release and they still got all the things here. 90% less bugs in production design interfaces. Everyone was happier. Now again, this sounds like like a dream scenario, [\[25:31\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1531s) But most development shops are afraid to do this development because they do not see the end numbers and it's hard to see. And because we had were lucky to do this experiment, usually in real life, it takes a few good months to see the effects of test-driven development. probably five, six months to see the effects on the release cycles because it takes time to learn to adapt and it's very hard for management to give a good back to to give a good backing to this idea. [\[26:02\]](https://www.youtube.com/watch?v=6lUpQAV8dn4&t=1562s) But if you do look at the bottom line and you are able to to weather through the storm of difficulty, then what you end up with are definitely happier customers and happier developers. ## Related - [Testing the test](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2) · The Art of Unit Testing, 3rd ed., ch. 2 The 3rd edition's section on testing the test by seeing it fail, the first answer to why tests are written before the code. - [Is there proof that unit testing helps?](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-11) · The Art of Unit Testing, 3rd ed., ch. 11 Section answering whether there is proof that unit testing helps, the question behind the two-team numbers shown here. - [An updated diagram of the TDD process from the upcoming 3rd Edition of Art of Unit Testing](https://osherove.com/blog/2019/11/12/an-updated-diagram-of-the-tdd-process-from-the-upcoming-3rd-edition-of-art-of-unit-testing) · osherove.com Roy's diagram of the TDD process, a picture of the one-failing-test-at-a-time cycle discussed here. ### Also linked in this lesson #### The Art of Unit Testing, 3rd ed. - [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_27), ch. 1 - [Three core skills needed for successful TDD](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_29), 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 #### The Art of Unit Testing, 2nd ed. - [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec6), ch. 1 - [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4 #### 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) - [Test Coverage and testing angles](https://osherove.com/blog/2005/4/3/test-coverage-and-testing-angles.html) - [TDD Kata 1 - String Calculator](https://osherove.com/tdd-kata-1) #### pipelinedriven.org - [Pattern: Shipping Skeleton](https://pipelinedriven.org/article/2014/3/2/pattern-shipping-skeleton) [Previous lesson Simplicity is Complicated](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/simplicity-is-complicated/) [Next lesson Mocks, Stubs and Fakes](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/mocks-stubs-and-fakes/) --- ## 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/