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...