The course is part of this learning path
Test-Driven Development (TDD) is a discipline that helps to create error-free, quality code, and drives productivity by reducing and eliminating errors as well as providing many other benefits.
This entry-level training course is designed to bring you quickly up to speed with the basic features and processes involved in performing Java based test-driven development using JUnit5. It covers the key principles and practices of test-driven development, which you can then utilize within your own software engineering projects.
In this course, you'll be guided through an end-to-end sample project in which we use test-driven development to build, test, and package a Java 11 based library that will provide an API to convert Bitcoins into foreign currency.
If you have any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Understand the fundamentals of TDD and JUnit5
- Use TDD to build, test, and package a Java 11 based library
- Perform TDD by performing Red-Green-Refactor iterations
- Learn how to use TDD to build, test, and package a Java 11 based library
- Learn how to create unit tests using the JUnit5 testing framework
- Software developers interested in using TDD to build JDK11 based applications using Java
To get the most out of this course, you should have a basic understanding of JDK11 and the Java programming language, as well as software development and the software development life cycle (SDLC).
Welcome back. In this lesson, I'll provide a quick introduction to JUnit5, which is a super easy-to-use Java-focused unit testing framework. I'll be using JUnit5 later on in the provided test-driven development unit testing demonstrations. I'll cover off the basics of installing JUnit5 and writing and executing JUnit5 based tests.
For starters, let's take a quick look at how you would go about setting up a brand new Java project, pre-configured with the JUnit5 library available, thereby making the project ready to contain JUnit5 based unit test. For this part of the lesson, I'll use the example of a simple calculator class that provides a method which sums up two numbers together.
Now, when it comes to installation or project setup, getting all the pieces to work together in unison in the Java landscape can be at times challenging. Especially for those starting out on this journey. To help with this, I've created a Java 11 and JUnit5 Maven Archetype, which in layman's terms can be used to quickly and easily launch and scaffold out a new project, on the file system, of the mechanics for performing test-driven development, all wired up and ready to go. It's as simple as running the following commands, assuming you already have both the JDK11 and Maven 3 pre-installed.
Within your terminal, first install the Cloud Academy provided custom Java 11 and JUnit5, Maven Archetype locally. Next, generate a new Java 11 and JUnit5 based project running the following command. The outcome of running this command is a newly formed Java based project. The project structure created on the local file system follows a particular convention managed and known by Maven.
The directory structure provides separate subdirectories for both the application source and the unit tests. The sample project contains an example calculator class, and corresponding calculator test, unit test. Two, demonstrate the basics of writing and configuring unit tests. This project also comes with its own Maven POM File which contains all of the required dependencies, to create and run JUnit5 based unit test. With this project set up as it is, you can simply compile and kick off the Junit5 based unit test within it, by simply running the following Maven command, Maven clean test.
Now that our JUnit unit testing project has been established we can simply add new test classes to it. Such as the following. In this JUnit unit test example, we can see the following code parts which make up the unit test. Both import statements near the top are use to pull on both the JUnit tests and Assertion types. The add two numbers gives correct result method, is tagged with the test annotation to indicate that it's a test method.
At runtime, the JUnit test runner will know to execute any and all methods annotated this way. Internally, the add two numbers gives correct result test method is composed using the known arrange, act, assert pattern, which is a standard and best practice pattern for writing tests. Again, the arrange part is used to set up the code under test. Here, objects being tested get instantiated. Marks are fused, to set up and expectations are set. The act part executes the method and behavior being tested. And finally, the assert section is used to check whether the specified expectations were met or not.
Mostly, this is how unit tests are developed and structured using JUnit5. As you can see, authoring JUnit5 based test, is a fairly simple activity. JUnit5 provides a few other types that can be used to structure your unit test, and other variations. Now, when it comes to actually asserting conditions, about your code and more importantly, the run-time behavior of it, JUnit5 provides numerous types of assertions including those that can assert failure outcomes or runtime exceptions, et cetera.
The following list highlights many of the different JUnit5 assertion options. Note, this is not a comprehensive list but, rather a list of the more commonly used ones. Most, if not all of these assertions, are self-explanatory in terms of their names et cetera. For the full list of assert methods available, consider consulting the inbuilt and tally sense from within your IDE, as you go about coding your unit test. Specifically, on the assertions type when using it, or consider reviewing the JUnit5 online documentation found here.
JUnit5 provides the ability to configure, Setup and Teardown flows to run immediately before and after each and every test. Setup code allows you to set up and perform initializations of objects and or prepare test state. Setup code can be instructed to run exactly once, before all tests are executed, using the peripheral annotation, marked on a static method. Or multiple times, there being once before each test is executed, using the BeforeEach annotation, marked on a non-static method.
For example, consider the following. When this unit test is executed, the do this method, will be called exactly once before all remaining test methods are invoked. Now, consider the following alternative example, which leverages the BeforeEach annotation. When this unit is executed, the do this method will be called once for each declared test method and is invoked immediately before each test method runs.
At the other end of a test run, JUnit can be instructed to perform Teardowns. This is accomplished by using either the AfterAll and AfterEach annotations. Both of these annotations behave in a similar way to their counterparts. Just that they performed their work after the tests have been run.
Okay, that now completes, this lesson on the JUnit5 framework. In this lesson, you learned about what JUnit5 is. You learnt how to create and configure a Java 11 and JUnit5 enabled unit testing project using Maven and a Cloud Academy, custom provided Maven Archetype. You learned about how easy it is to write unit tests using the JUnit5 test provided annotation. You learned about the various assertions that can be called upon to test the run-time behavior of your classes. And finally, you learned that JUnit5 provides Setup and Teardown options for writing unit tests if required.
Go ahead now and close this lesson. And I'll see you shortly in the next one.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).