Test Driven Development with JUnit 5
-
Share:
-
-
-
Abstract: In this series of articles, we will show you how to develop safe, flexible applications using test-driven development (TDD). A technique that can greatly increase development speed and eliminate much of the debugging nightmare—all with the help of JUnit 5 and its features. We will point out the main concepts involved in TDD and apply them in developing a Java application that implements the business logic for managing flights and passengers and following a set of policies. Our focus will be on clearly explaining TDD and proving its benefits by demonstrating how to put it in practice, step by step.
1. TDD main concepts
Test-driven development is a programming practice that uses a short, repeating development cycle in which requirements are converted into test cases and then the program is modified to make the tests pass:
- Write a failing test before writing new code.
- Write the smallest piece of code that will make the new test pass.
This is different from traditional software development, where code may be added without having to verify that it meets requirements. In a classical approach, developing a program means we write code and then do some testing by observing its behavior. So, the conventional development cycle goes something like this: [code, test, (repeat)]
TDD uses a surprising variation: [test, code, (repeat)]
The test drives the design and becomes the first client of the method.
TDD’s benefits include the following:
- We write code that is driven by clear goals, and we make sure we address exactly what our application needs to do.
- Introducing new functionality is much faster. On the one hand, tests drive us to implement code that does what it is supposed to do. On the other hand, tests will prevent us from introducing bugs into the existing working code.
- Tests act as documentation for the application. We can follow them and understand what problems our code is supposed to solve.
We said that TDD uses this development cycle: [test, code, (repeat)]. In fact, it looks like this: [test, code, refactor, (repeat)].
Refactoring is the process of modifying a software system in a way that does not impact its external behavior but does improve its internal structure. To make sure external behavior is not affected, we need to rely on the tests.
When we receive specifications to add new functionality to an application, we have to first understand them before we can add them to the code. What if we first implement a test that will show us what we have to do, and then think about how to do it? This is one of the fundamental principles of TDD.
When we begin working on an application, at the very least, we need to understand the fundamental idea of what the software is supposed to do. But if we want to check what classes or methods do, our choices are limited: read the documentation or look for sample code that invokes the functionality. Most programmers prefer to work with the code. And well-written unit tests do exactly this: they invoke our code and, consequently, provide a working specification for the code’s functionality. As a result, TDD effectively helps to build a significant part of the application’s technical documentation.
Tudose, Florin-Catalin Tudose
