--- title: "Simplicity is Complicated" url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/simplicity-is-complicated.md" canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/simplicity-is-complicated/" tags: [] author: "Roy Osherove" description: "Lesson 5 of 21 in The Art of Unit Testing and TDD in Java (Day 1), 11:37. 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/" --- # Simplicity is Complicated 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 5 of 21 Duration: 11:37 [Watch on YouTube](https://www.youtube.com/watch?v=zSiFwGJ31Ew) What do I mean when I say "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)")"? ## In this lesson Roy Osherove judges how simple a solution is by how close it is to the beginning of the method and how little it is indented. He test-drives a parse method on the [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)"), starting with an empty string that returns zero, and treats each hard-coded answer as an assumption that the next failing test, such as a single number, proves wrong. He connects these small steps to incremental development in micro iterations, with new working code that could be released every day. ## Transcript 1,682 words [\[00:03\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=3s) And I want to talk about simplicity. Sometimes when we 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)"), what we want to do is to solve it visually. We can measure how to actually measure something in terms of simplicity. And the only way I found to say whether code is simpler or not is whether the solution that I have is closer to the beginning of the method and whether it's more indented or less indented. So if it if it has more indentation like inside a loop or an if, it's more complicated than if it's not inside a loop or an if. [\[00:35\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=35s) Agreed? Also if I have to put something as a solution to make a test pass as the third line of code in a production code, that's not as simple as making it the first line of code. Maybe that makes a little less sense. So let me explain. If your code ends up here instead of here, that means that it that to actually execute your code, all the following things just above it had to execute, right? So that means that your code has to assume that something's happened before. [\[01:09\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=69s) That makes it more complicated or at least to understand the solution would be more complicated. If your code is the first line of code, if the if to make a test pass, you just add one line of code at the beginning of the method, that's the simplest thing because you don't make any assumptions about what happened before. You just do something in the simplest way possible and almost blindly. For example, clean up the inputs or things like that. And that's an example of simplicity. And we're going to find that simplicity is actually a bit difficult to achieve when we do the [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)"). [\[01:45\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=105s) Now when I do [test-driven development](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)") I basically practice the idea that I remove as many assumptions from my code as possible but I might write my code with as many assumptions as I can about the inputs. So I'll give you an example. Let's say that the string calculator has a method called add public void. Let's call it parse [\[02:20\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=140s) And parse can take a string with multiple numbers and those numbers can be divided with commas. Okay. And then the idea of parse is it will parse the numbers and sum them up and give you the number. Okay. So if I wanted to test parse and parse doesn't exist yet. I want to start with something then I have to start and I might start there are many ways I could start this test right but I want to start with the simplest test possible as well. So I want to start with the simplest inputs. [\[02:51\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=171s) For example I can assume that the input is an empty string in which case I would just say no numbers. let's return zero. That's better than sending in three numbers because that's something that I can incrementally work towards adding more and more features. And I can go ahead and say parse add parse an empty string returns zero or I can say returns a default. In this case I would say zero [\[03:24\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=204s) Summation. So I can say make calc extract a variable. Oh, that's not it. Extract a variable and say string calculator dot what was it? String calculator dot parse. And here I'm just going to give it an empty string. [\[04:01\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=241s) What I'm going to say now is that we basically have int result equals u parse of an empty string. And here I would say assert equals what do I expect? What is the expected value from an empty string? If you're not sure, just look at the name of the test. What is it? Thank you. Zero from result. [\[04:37\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=277s) Now if I just run this, this will of course not compile. But I can go ahead and say create the method string numbers and now I can say just return minus one because I want to see the test fail. Remember I'm just going to run the tests. Expected one that was minus one. That's what I wanted. [\[05:07\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=307s) Now I'm going to just make the test pass. So now the question is if I wanted to make the test pass in the simplest way possible, what can I send in? What should I write? Do I have to check the string? No, I can make an assumption. I can just say, hey, you know what? I'm the laziest developer in the world. I'm just going to return zero. How's that? Return zero. And I know that feels horrible. [\[05:39\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=339s) But that's kind of the point of making too many assumptions because now it feels horrible. All the tests pass and I'm back to the first rule of TDD. You want to change it. You cannot without a failing test, right? You if you think something's wrong, prove the assumption wrong. So now I get to write a new test that says you can't assume that the input is always empty. Here's an example. And I would go and I say, okay, let's do this. [\[06:16\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=376s) I'm going to write this test. Parse single number because single number is easier than multiple numbers, right? Returns that number. Here I'm going to say give me what number should I send in? One. Thank you. Not 42. That's right. And we expect Z one. And now I'm just going to run my test again. Expected one actual zero. And now I've proven that the assumption is wrong. [\[06:46\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=406s) So it's like an onion. And you start with implementing the code with as many layers of assumptions as you can. Then every new test you basically peel out one layer of the says, "Oh, that can't be true. That can't be true." So now I get to go and say, "Okay, it can't always be zero. So what's the next simplest thing that I can assume if I have to make both of the tests pass in the same time? So I might say look let's just do an if if numbers length is [\[07:19\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=439s) Zero then return zero otherwise hey let's just return one because obviously if it's not an empty string it has to be the number one right that's an assumption right there let's do that do all the tests pass damn So now we're back in the same crappy situation we were. We don't like the code, but we don't have a failing test. So we can go back and say, "No, you can't make that assumption as well, dude. [\[07:50\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=470s) So let me go back and say, actually, if you send it with a different number, so I'm just going to send in a different number." So I just have the exact same test. I'm going to send in two. I'm going to send in two. And I'm going to run the test again. Of course, that fails. Now I know I can't just return one. I can I have to do like a integer parse int [\[08:20\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=500s) Numbers. Notice that I I assume that there's only one number obviously. Now here's a question. Oh, maybe I can just get rid of all these things. Do I can I? Let's see what happens. Oops, I can't. But how long did it take me to figure that out? A few seconds. And that's kind of the another point is that when you have the tests, you can experiment and say, can I get rid of that? [\[08:57\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=537s) Can I get rid of the loop? And you have less fear in your heart when you do that. So now I know these two things have a reason to exist. And guess what? My code works incrementally. So I have two of three features working. I have zero numbers working and I have one number working and I did it within a few minutes. I can actually demo my code and instead of saying my feature either works or it doesn't, I can say that my feature partially works and I can show examples of what works and what doesn't. [\[09:29\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=569s) That's an example of incremental development. I basically did micro iterations. So with every minute or every 10 minutes I have a new feature sub feature working. That means that every day I have new functionality in the application working with tests. If every day I have new functionality I can basically take the code and release it every day if I wanted to. I don't have to wait two weeks until the feature is either finished or not. I can release every day because I always have something new passing, new working. [\[09:59\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=599s) And that's an example of how you you make short iterations work is because if you have micro iterations in your code, then a release date is just a date and iteration and end of an iteration demo is just another day because you can demo on the first day of the iteration and in the middle day and every day because you always have new features and you're working incrementally instead of taking your build a big bulk of code and making pass. [\[10:32\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=632s) Here you're making very little increments. And you also have much better feeling because you have a lot of small wins. You see green and seeing green instead of red for two weeks is a much better feeling. [\[11:04\]](https://www.youtube.com/watch?v=zSiFwGJ31Ew&t=664s) So that's the idea of making the assumptions and remove the assumptions one by one from your code. So if I have an input, it will always be empty. Nope, that's wrong. Here's a test that proves it. And it also helps if you think about it wearing two hats. One hat is the person who makes who writes the tests and the other hat is for the person who's the laziest developer in the world who has to go home in five minutes. What would they do? And then they do it in the simplest way and then the other guy says, "Oh, no, you can't do that. ## Related - [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) · osherove.com Roy's post on what 'the simplest thing that could possibly work' means in TDD, this lesson's question. - [Measuring Simplicity in TDD](https://osherove.com/blog/2011/1/20/measuring-simplicity-in-tdd.html) · osherove.com Roy's post on whether there is an order of simplicity when changing code to pass a failing test. - [TDD Kata 1 - String Calculator](https://osherove.com/tdd-kata-1) · osherove.com The String Calculator kata, starting with the empty string returning zero as test-driven in this lesson. - [Comments on Corey Haines’ String Calculator TDD Kata Implementation](https://osherove.com/blog/2009/12/23/comments-on-corey-haines-string-calculator-tdd-kata-implemen.html) · osherove.com Roy's comments on a recorded String Calculator kata solution, a worked example of the same small steps. ### 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 [Previous lesson Introducing TDD](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/introducing-tdd/) [Next lesson Common TDD Questions and Answers](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/common-tdd-questions-and-answers/) --- ## 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/