--- title: "Unit Testing Demo" url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/unit-testing-demo.md" canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/unit-testing-demo/" tags: [] author: "Roy Osherove" description: "Lesson 3 of 21 in The Art of Unit Testing and TDD in Java (Day 1), 7:30. 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/" --- # Unit Testing Demo 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 3 of 21 Duration: 7:30 [Watch on YouTube](https://www.youtube.com/watch?v=eEluzywvVwk) A short demo about jUnit basics. ## In this lesson In IntelliJ, Roy Osherove shows [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)") tests that use [helper methods](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec6 "Building a test API for your application (The Art of Unit Testing, 2nd ed., ch. 7)") called make calc and assert adding to avoid repetition and keep the tests [maintainable](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8 "Maintainability (The Art of Unit Testing, 3rd ed., ch. 8)"). He then compares ways to test that a line throws an exception in [JUnit](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2#sigil_toc_id_39 "The xUnit frameworks (The Art of Unit Testing, 3rd ed., ch. 2)"): a try/catch block, the expected parameter of the test annotation, which he advises against because any line can throw, and an [expected exception rule](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2 "Checking for expected thrown errors (The Art of Unit Testing, 3rd ed., ch. 2)"). With the rule, only the lines after the expect call are supposed to throw the exception. ## Transcript 890 words [\[00:03\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=3s) Let me show you a little bit of features here. This is IntelliJ Let's see if I can just close others should be okay. [\[00:36\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=36s) So what I'm showing here is a class called [string calculator](https://osherove.com/tdd-kata-1 "TDD Kata 1 - String Calculator (osherove.com)"). So I have a package here called [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)") and I have a class called string calculator. And there's a lot of logic but the logic is pretty simple. It basically parses out numbers and it checks if there are like negative numbers. It throws exception. If there's an empty input, then it returns a default value. And you'll notice that a lot of this is just calls to different smaller methods. [\[01:11\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=71s) And what what happens is that usually with testdriven development, you start with something and you refactor into new methods. So what we're going to do is I just want to show you how the tests look. So I have a class called string calculator tests. I have a [helper method](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8#sigil_toc_id_161 "Keep tests DRY (The Art of Unit Testing, 3rd ed., ch. 8)") called make calc. And this is one of the reasons that I want to be able to have [maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-8#ch08lev1sec2 "Writing maintainable tests (The Art of Unit Testing, 2nd ed., ch. 8)") is is achieved. [\[01:41\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=101s) One of the ways to achieve maintainability is by not creating the string calculator directly in my tests but by having it directly called by a helper method. So this is an example of creating the calculator and I actually have a method called assert adding and in assert adding what I do is I basically have this little test right here. I started with a little test and I saw hey I keep repeating myself. [\[02:14\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=134s) So maybe I'll just call add here and I will just assert against it and that will help me remove some of the repeating in the code. So I came up with a helper method. This is not a test but it does have an assert inside it. Another feature that's important is when we want to test [\[02:47\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=167s) A line like this. Let's say if there's a number that's negative, throw an illegal argument exception. How do I test a line that throws an exception in [JUnit](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2#sigil_toc_id_39 "The xUnit frameworks (The Art of Unit Testing, 3rd ed., ch. 2)")? Well, there are several ways. One way is to use try catch, but there are that's usually frowned upon these days. because it makes the test very very unreadable. Basically, if I wanted to, I would write something like this. Test public [\[03:18\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=198s) Void add with negative rows. I just call it zero because they have different examples of that. And then here I would say try minus one. And here I might say catch [\[03:48\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=228s) I could choose the exception and throwable E. And here I might say look if you got all the way to the exception all good. Okay, I can just say return. But if you got all the way out of the exception [\[04:19\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=259s) And I can say assert false true, I can make the test fail on purpose and say [expected exception](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec6 "More NUnit attributes (The Art of Unit Testing, 2nd ed., ch. 2)"). And that's an example of how you would how would you would make the test fail on purpose. I usually just say this because the name of the test is good enough that I don't have to give to give a good comment. [\[04:52\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=292s) So that's the like the that used to be the the good way of doing things because you wanted to say okay this line is supposed to throw an exception but then with the latest version of JUnit I could just say test and say expected equals illegal argument exception.class. Don't use this. Okay, I'm showing you so that you know not to use this. And the reason is it's basically putting the whole test in a big try catch. [\[05:24\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=324s) What's the problem with that? Means that any line can throw that exception. So if the wrong line throws an exception, something in the [arrange part](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2 "The Arrange-Act-Assert pattern (The Art of Unit Testing, 3rd ed., ch. 2)") for example, your test will actually pass. It will lie to you. Okay. So expected exception is something that exists that you should not use. Here's a bit of a cleaner way to do it. You create something called a rule. A rule is something that you can set that applies to all the tests. For example, I set a rule and then a public field expected exception and I call it thrown. [\[05:59\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=359s) And I say the expect the default of expected exception is none. This is part of the JUnit APIs. And then in my test I would say make the calculator and then I would say thrown expect illegal argument exception.class. And here I would have that line. So now only the lines that appear after this line are the ones that are supposed to throw the exception. Okay. [\[06:30\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=390s) Now why is that important? because it allows me to say that this line shouldn't throw an exception. If this line throws that exception, my test will fail. But if this line throws an exception, my test will pass. So I'm able to say that specific line is the important one. And if you if you if you don't like this rule, this working with rules, you can always go back to try catch. That's the And you'll notice that even in try catch you can actually make that mistake of saying oh just make the calc. [\[07:02\]](https://www.youtube.com/watch?v=eEluzywvVwk&t=422s) So here I'm just going to extract a variable from it. And now this line is the only nine that's supposed to throw an exception. ## Related - [Checking for expected thrown errors](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 checking for expected thrown errors, the exception-testing options compared in the demo. - [Keep tests DRY](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8#sigil_toc_id_161) · The Art of Unit Testing, 3rd ed., ch. 8 Section on keeping tests DRY, the reason the demo uses make calc and assert adding helper methods. - [Writing maintainable tests](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-8#ch08lev1sec2) · The Art of Unit Testing, 2nd ed., ch. 8 The 2nd edition's section on writing maintainable tests, which the helper methods in the demo aim for. ### Also linked in this lesson #### The Art of Unit Testing, 3rd ed. - [Maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8), ch. 8 - [The xUnit frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-2#sigil_toc_id_39), ch. 2 - [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 #### The Art of Unit Testing, 2nd ed. - [Building a test API for your application](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec6), ch. 7 - [More NUnit attributes](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec6), ch. 2 #### osherove.com - [TDD Kata 1 - String Calculator](https://osherove.com/tdd-kata-1) [Previous lesson Introduction to JUnit](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/introduction-to-junit/) [Next lesson Introducing TDD](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/introducing-tdd/) --- ## 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/