--- title: "Common TDD Questions and Answers" url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/common-tdd-questions-and-answers.md" canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/common-tdd-questions-and-answers/" tags: [] author: "Roy Osherove" description: "Lesson 6 of 21 in The Art of Unit Testing and TDD in Java (Day 1), 5:49. 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 TDD Questions and Answers 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 1 Lesson 6 of 21 Duration: 5:49 [Watch on YouTube](https://www.youtube.com/watch?v=wLV5RT8cJIU) Why not write many tests at once? Why start with a failing test? why solve things in 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)")? These and many more questions are covered in this short talk. ## 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, and because there is never time to write them after the code. He says [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)") makes developers try to prove that their code doesn't work, that the [tests remove the fear of refactoring](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-11 "What about TDD? (The Art of Unit Testing, 3rd ed., ch. 11)"), and that [doing the simplest thing](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)") avoids writing code nobody uses. He also explains why he has only one failing test at a time and writes the planned tests as comments. ## Transcript 1,030 words [\[00:06\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=6s) Okay. Common questions about about [TDD](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)"). Why write the test before the code? First of all, it's about testing the test. Remember so we think through the requirements and we also look at the design of requirement and that gives us a lot of a lot of problem solving abilities. Someone wrote that TDD is an excuse to think about the problem before thinking about the solution. And I think that's absolutely true. Many times we think about the solutions and we fix the wrong problem. [\[00:38\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=38s) And a lot of times what happens when you do TDD is that you spend much more time trying to understand what it is you're doing and why you're doing it and what's the point. A lot of times you say, "Oh, I shouldn't have built that one." So it makes you talk much more with your customers. You make it fail first so you can [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)"). And also I forgot to say that you write the test before the code because you never have time to write the test after the code. So if you write it before you always have time to do it. [\[01:11\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=71s) We make it fails fail first because we define one problem to solve. So, I chose one problem and then I made that pass and then another problem made that pass. I don't have five different failing tests at the same time. I have one. That's kind of the point. I don't want to have a big problem solved, just a small one. And when I do solve it, I solve it as simply as possible. And that forces me to think about new tests. Because if you think about it, as developers, we're usually very not objective about our code. [\[01:44\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=104s) We assume that it works. So when we write tests for the code after it's passing we assume we're trying to prove that the code works. And with TDD the objective is to prove that the code doesn't work. So we're thinking much more like testers. So TDD is a good way to force yourself to think about how to break your code instead of how to prove that it works. That makes the code much more resilient in terms of quality. So the simpler solutions force you to do that to say no that's assumption is wrong let's prove that that's wrong prove that that's wrong and it also usually find that your code will be much simpler than you thought it will ever be and that's a nice thing you you start with the solution in mind but you just keep doing very very small steps and suddenly everything passes and you didn't even do half of the things that you thought you will do and that's a great feeling [\[02:39\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=159s) The refactoring part which we haven't done yet is the the part where you make the code much much easier to read. And one example is that you constantly improve the the readability and the design of the code by extracting small methods from big methods. And if we don't do it, our code is going to be very very ugly although it will pass all the tests. And one of the nice things about having those tests as a side u as a side benefit is that because you have the tests you have no fear of refactoring. [\[03:12\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=192s) So one of the things that always happens in projects is that people are afraid to change the code. So they copy and they create a new version of the code with the changes they would like because they don't want to break the original code. And that's how code has children. Basically, the code becomes bigger and bigger and more disgusting because everything looks like a copy of everything else because everyone is afraid to change everything. And then at some point, someone says, "Ah, let's just rewrite the whole thing." And one of the nice things with this is that you're not afraid to change the code. So, it looks like like a plant that you keep growing and trimming and watering instead of replacing the plant every year. [\[03:49\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=229s) You're just cutting the leaves where you need to. And the incremental work is very important because usually when we over plan something we don't use all the features. So imagine using something like Microsoft Word. How many of the features of Word have you actually used? Maybe 10%. Think about all the code that you've written in the hope or in the idea that someone might want to use it. How much of that actually gets used? By studies we've seen that [\[04:23\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=263s) 60% of the code that you write usually doesn't get used. So you're writing 60% of code that you're just wasting time on average. So instead of doing that instead of planning over planning for the future we do just 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 "TDD: 4 questions that will help you create the simplest thing that could possibly work (osherove.com)") and that saves us from the future risks of overarchitecture and things like that. It's also a great feeling to have this passing, this passing, this passing instead of having one big feature that works after a month. [\[04:58\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=298s) And again, I covered the idea of why not write this multiple tests at once. I might write comments of tests that I will have because I don't want to forget, but I don't have 10 failing tests at the beginning. I have one failing and then I write another that fails. I might have 10 comments but I don't have 10 failing tests. That's important so that psychologically I am focused on a specific set of problems. For example, if you have three failing tests on [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)"), you might be tempted to fix all of them at the same time and that would make you write code much more complicated than you would. [\[05:34\]](https://www.youtube.com/watch?v=wLV5RT8cJIU&t=334s) You might end up with code much more complicated you would have if you solved it one at a time. So by separating it, you're actually making it easier for yourself to think only on very small problems and not solve too many problems that maybe you didn't even test ## 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, the first reason given here for writing tests before the code. - [What about TDD?](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-11) · The Art of Unit Testing, 3rd ed., ch. 11 The book's answer to 'What about TDD?' among its tough questions and answers, matching this Q&A lesson. - [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec6) · The Art of Unit Testing, 2nd ed., ch. 1 The 2nd edition's section on test-driven development, explaining why tests come first and stay small. ### 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 #### 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) - [TDD Kata 1 - String Calculator](https://osherove.com/tdd-kata-1) [Previous lesson Simplicity is Complicated](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/simplicity-is-complicated/) [Next lesson Some Numbers](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/some-numbers/) --- ## 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/