JUnit in Action

Catalin Tudose

• Publisher: Manning
• Year: 2020
• Print ISBN: 9781617297045
• eBook ISBN: 9781638356554
• Topic: Computer Science
• Subtopic: Programming in Java
• Index: Computer Science

JUnit in Action, Third Edition has been completely rewritten for this release. The book is full of examples that demonstrate JUnit's modern features, including its new architecture; nested, tagged, and dynamic tests; and dependency injection. Summary
JUnit is the gold standard for unit testing Java applications. Filled with powerful new features designed to automate software testing, JUnit 5 boosts your productivity and helps avoid debugging nightmares. Whether you're just starting with JUnit or you want to ramp up on the new features, JUnit in Action, Third Edition has you covered. Extensively revised with new code and new chapters, JUnit in Action, Third Edition is an up-to-date guide to smooth software testing. Dozens of hands-on examples illustrate JUnit 5's innovations for dependency injection, nested testing, parameterized tests, and more. Throughout, you'll learn how to use JUnit 5 to automate your testing, for a process that consumes less resources, and gives you more time for developing. Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the technology
The JUnit framework is the gold standard for unit testing Java applications—and knowing it is an essential skill for Java developers. The latest version, JUnit 5, is a total overhaul, now supporting modern Java features like Lambdas and Streams. About the book
JUnit in Action, Third Edition has been completely rewritten for this release. The book is full of examples that demonstrate JUnit's modern features, including its new architecture; nested, tagged, and dynamic tests; and dependency injection. You'll benefit from author Catalin Tudose's unique "pyramid" testing strategy, which breaks the testing process into layers and sets you on the path to bug-free code creation. What's inside Migrating from JUnit 4 to 5
Effective test automation
Test-driven development and behavior-driven development
Using mocks for test isolation
Connecting JUnit 5 with Maven or Gradle About the reader
For intermediate Java developers. About the author
Catalin Tudose has a Ph.D. in Computer Science, and over 15 years of experience as a Senior Java Developer and Technical Team Lead. Previous editions were authored by Petar Tahchiev, Felipe Leme, Gary Gregory, and Vincent Massol. Table of Contents PART 1 - JUNIT 1 JUnit jump-start 2 Exploring core JUnit 3 JUnit architecture 4 Migrating from JUnit 4 to JUnit 5 5 Software testing principles PART 2 - DIFFERENT TESTING STRATEGIES 6 Test quality 7 Coarse-grained testing with stubs 8 Testing with mock objects 9 In-container testing PART 3 - WORKING WITH JUNIT 5 AND OTHER TOOLS 10 Runing JUnit tests from Maven 3 11 Running JUnit tests from Gradle 6 12 JUnit 5 IDE support 13 Coninuous integration with JUnit 5 PART 4 - WORKING WITH MODERN FRAMEWORKS AND JUNIT 5 14 JUnit 5 extension model 15 Presentation-layer testing 16 Testing Spring applications 17 Testing Spring Boot applications 18 Testing a REST API 19 Testing database applications PART 5 - DEVELOPING APPLICATIONS WITH JUNIT 5 20 Test-driven development with JUnit 5 21 Behavior-driven development in JUnit 5 22 Implementing a test pyramid strategy with JUnit 5

Part 1. JUnit

Welcome to JUnit in Action, which covers the JUnit framework, started by Kent Beck and Erich Gamma in late 1995. Ever since then, the popularity of the framework has been growing; now JUnit is the de facto standard for unit testing Java applications.

This book is the third edition. The first edition was a best seller, written by Vincent Massol and Ted Husted in 2003 and dedicated to version 3.x of JUnit. The second edition was also a best seller, written by Petar Tahchiev, Felipe Leme, Vincent Massol, and Gary Gregory in 2010, and dedicated to version 4.x of JUnit.

In this edition, I cover version 5.x of JUnit--the newest version--and talk about lots of features included in it. At the same time, I focus on interesting details and techniques for testing your code: the architecture of the framework, test quality, mock objects, interaction with other tools, and JUnit extensions, as well as testing layers of your application, applying the test-driven development and behavior-driven development techniques, and so forth.

This part of the book explores JUnit itself. Chapter 1 gives you a quick introduction to the concepts of testing--knowledge you need to get started. I get straight to the code, showing you how to write and execute a very simple test and see its results. Chapter 2 introduces JUnit in detail. I show JUnit 5’s capabilities and walk through the code that puts them in practice. Chapter 3 looks at JUnit architectures, and chapter 4 discusses how to make the step from JUnit 4 to JUnit 5 and how to migrate projects between these versions of the framework. Chapter 5 is dedicated to tests as a whole. The chapter describes different kinds of tests and the scenarios to which they apply. I discuss different levels of testing and the best scenarios in which to execute those tests.

1 JUnit jump-start

This chapter covers

• Understanding JUnit
• Installing JUnit
• Writing your first tests
• Running tests

Never in the field of software development was so much owed by so many to so few lines of code.

--Martin Fowler

All code needs to be tested. During development, the first thing we do is run our own programmer’s acceptance test. We code, compile, and run. When we run, we test. The test may just consist of clicking a button to see whether it brings up the expected menu or looking at a result to compare it with the expected value. Nevertheless, every day, we code, we compile, we run, and we test.

When we test, we often find issues, especially during early runs. So we code, compile, run, and test again.

Most of us quickly develop a pattern for our informal tests: add a record, view a record, edit a record, and delete a record. Running a little test suite like this by hand is easy enough to do, so we do it--over and over again.

Some programmers like doing this type of repetitive testing. It can be a pleasant break from deep thought and hardcoding. When our little click-through tests finally succeed, we have a real feeling of accomplishment (“Eureka! I found it!”).

Other programmers dislike this type of repetitive work. Rather than run the tests by hand, they prefer to create a small program that runs the tests automatically. Play-testing code is one thing; running automated tests is another.

If you’re a “play-test” developer, this book is for you. It shows you that creating automated tests can be easy, effective, and even fun.

If you’re already test-infected,1 this book is also for you. We cover the basics in part 1 and move on to tough, real-life problems in parts 2-5.

1.1 Proving that a program works

Some developers feel that automated tests are essential parts of the development process: you cannot prove that a component works until it passes a comprehensive series of tests. In fact, two developers felt that this type of unit testing was so important that it deserved its own framework. In 1997, Erich Gamma and Kent Beck created a simple but effective unit testing framework for Java called JUnit: they were on a long plane trip, and it gave them something interesting to do. Erich wanted Kent to learn Java, and Erich was interested in knowing more about the SUnit testing framework that Kent created earlier for Smalltalk, and the flight gave them time to do both.

DEFINITION Framework--A semicomplete application that provides a reusable common structure to share among applications.2 Developers incorporate the framework into their own applications and extend it to meet their specific needs. Frameworks differ from toolkits by providing a coherent structure rather than a simple set of utility classes. A framework defines a skeleton, and the application defines its own features to fill out the skeleton. The developer code is called appropriately by the framework. Developers can worry less about whether a design is good and focus more on implementing domain-specific functions.

If you recognize the names Erich Gamma and Kent Beck, that’s for a good reason. Gamma is one of the Gang of Four who gave us the now-classic Design Patterns book.3 Beck is equally well known for his groundbreaking work in the software discipline known as Extreme Programming (www.extremeprogramming.org).

JUnit quickly became the de facto standard framework for developing unit tests in Java. Today, JUnit (https://junit.org) is open source software hosted on GitHub, with an Eclipse Public License. And the underlying testing model, known as xUnit, is on its way to becoming the standard framework for any language. xUnit frameworks are available for ASP, C++, C#, Eiffel, Delphi, Perl, PHP, Python, Rebol, Smalltalk, and Visual Basic--to name just a few.

The JUnit team didn’t invent software testing or even unit tests, of course. Originally, the term unit test described a test that examined the behavior of a single unit of work: a class or a method. Over time, the use of the term unit test broadened. The Institute of Electrical and Electronics Engineers (IEEE), for example, has defined unit testing as “testing of individual hardware or software units or groups of related units” (emphasis added).4

In this book, we use the term unit test in the narrower sense to mean a test that examines a single unit in isolation from other units. We focus on the type of small, incremental test that programmers apply to their own code. Sometimes, these tests are called programmer tests to differentiate them from quality-assurance or customer tests (http://c2.com/cgi/wiki?ProgrammerTest).

Here is a generic description of a typical unit test from the perspective of this book: “Confirms that the method accepts the expected range of input and that the method returns the expected value for each input.” This description asks us to test the behavior of a method through its interface. If we give it value x, will it return value y? If we give it value z instead, will it throw the proper exception?

DEFINITION Unit test--A test that examines the behavior of a distinct unit of work. A unit of work is a task that is not directly dependent on the completion of any other task. Within a Java application, the distinct unit of work is often, but not a...

Table of contents

• JUnit in Action
• Copyright
• dedication
• contents
• front matter
• Part 1. JUnit
• 1 JUnit jump-start
• 2 Exploring core JUnit
• 3 JUnit architecture
• 4 Migrating from JUnit 4 to JUnit 5
• 5 Software testing principles
• Part 2. Different testing strategies
• 6 Test quality
• 7 Coarse-grained testing with stubs
• 8 Testing with mock objects
• 9 In-container testing
• Part 3. Working with JUnit 5 and other tools
• 10 Running JUnit tests from Maven 3
• 11 Running JUnit tests from Gradle 6
• 12 JUnit 5 IDE support
• 13 Continuous integration with JUnit 5
• Part 4. Working with modern frameworks and JUnit 5
• 14 JUnit 5 extension model
• 15 Presentation-layer testing
• 16 Testing Spring applications
• 17 Testing Spring Boot applications
• 18 Testing a REST API
• 19 Testing database applications
• Part 5. Developing applicationswith JUnit 5
• 20 Test-driven development with JUnit 5
• 21 Behavior-driven development with JUnit 5
• 22 Implementing a test pyramid strategy with JUnit 5
• appendix A. Maven
• appendix B. Gradle
• appendix C. IDEs
• appendix D. Jenkins
• index