Watch the Lesson

Creating a New Test Class

We can create a new test class by simply creating a public class. Even though there is no “official” naming convention, the most common way to name a unit test class is to add the suffix Test to the name of the tested class or unit.

Because we don’t write unit tests for a specific class, we will create a test class called: SetUpAndTearDownTest. Its source looks as follows:

public class SetUpAndTearDownTest {
}

JUnit 4 requires that all test classes are public.

Next, we will find out how we can add test methods to a test class.

Adding Test Methods to a Test Class

We can add a new test method to a test class by following these steps:

Add a public method to the test class and ensure that the method doesn’t return anything.

Annotate the method with the @Test annotation. This annotation tells to JUnit that the method in question can be run as a test case.

JUnit 4 requires that all test methods are public and don’t return anything.

Before we continue, I want to warn you about the problems found from this class. This test class has three problems:

First, the names of the test methods don’t describe the expected outcome. This means that if a test method fails, we have to read the source code of the test method before we know what the problem is. This is a waste of time.

Third, our test methods write information to System.out. It is OK to use System.out for debugging purposes (although I prefer to use a debugger), but we should never commit tests which use it to our version control system because these tests litter the output of our test suite.

I use this approach here because I want to demonstrate when our test methods are run and writing information to System.out is the easiest way to do it.

We just wrote our first test methods. This is a good start. However, if we are writing unit tests for a real-life application, we have to ensure that the system under test is set into a known state before our test methods are run. We can do this by using setup methods.

Using Setup Methods

JUnit 4 has two different setup methods which are described in the following:

First, JUnit 4 has a setup method that is invoked before each test method. This method is typically used for creating and configuring the system under test. This means that:

We should create the dependencies of the tested object in this method. In other words, if we want to use test doubles in our unit tests, we should create these test doubles in this method.

We should create the tested object in this method.

We can create this setup method by following these steps:

Add a public method to the test class, and ensure that the method doesn’t take any method parameters and doesn’t return anything.

Annotate the method with the @Before annotation. This annotation tells to JUnit that the method in question should be run before each method that is annotated with the @Test annotation.

JUnit 4 requires that the method annotated with the @Before annotation is public, doesn’t have any method parameters, and doesn’t return anything.

Let’s add a new setup method to our test class. This method prints the string: ‘Invoked before each test method’ to System.out.

After we have added this method to our test class, its source code looks as follows:

Second, JUnit 4 has a setup method that is invoked once before any test method is run. This method is typically used for performing resource intensive configuration that is shared by several test methods. For example, if we need to open a database connection, we should open it in this method.

We can create this setup method by following these steps:

Add a public and static method to the test class, and ensure that the method doesn’t take any method parameters and doesn’t return anything.

Annotate the method with the @BeforeClass annotation. This annotation tells to JUnit that this setup method must be invoked once before any test method is run.

JUnit 4 requires that the method annotated with the @BeforeClass annotation is public, is static, doesn’t have any method parameters, and doesn’t return anything.

Let’s add a new setup method to our test class. This method prints the string: ‘Invoked once before all test methods’ to System.out.

After we have added this method to our test class, its source code looks as follows:

We can now use the setup methods supported by JUnit 4. Sometimes we reserve external resources in our setup methods. If we do so, we naturally have to free these resources as well. We can do this by using teardown methods.

Using Teardown Methods

JUnit 4 has two different teardown methods which are described in the following:

First, JUnit 4 has a teardown method that is invoked after each test method. We can use this method if we want to free the external resources which were reserved in the method annotated with the @Before annotation.

We can create this teardown method by following these steps:

Add a public method to our test class, and ensure that the method doesn’t take any method parameters and doesn’t return anything.

Annotate the method with the @After annotation. This annotation tells to JUnit that the method in question should be run after each method that is annotated with the @Test annotation.

JUnit 4 requires that the method annotated with the @After annotation is public, doesn’t have any method parameters, and doesn’t return anything.

Let’s add a new teardown method to our test class. This method prints the string: ‘Invoked after each test method’ to System.out.

After we have added this method to our test class, its source code looks as follows:

Second, JUnit has a teardown method that is invoked once after all test methods have been run. We can use this method if we want to free the external resources which were reserved in the method annotated with the @BeforeClass annotation.

We can create this teardown method by following these steps:

Add a public and static method to the test class, and ensure that the method doesn’t take any method parameters and doesn’t return anything.

Annotate the method with the @AfterClass annotation. This annotation tells to JUnit that this teardown method must be invoked once after all test methods have been run.

JUnit 4 requires that the method annotated with the @AfterClass annotation is public, is static, doesn’t have any method parameters, and doesn’t return anything.

Let’s add a new teardown method to our test class. This method prints the string: ‘Invoked once after all test methods’ to System.out.

After we have added this method to our test class, its source code looks as follows:

We can add test methods to our test class, and use the setup and teardown methods supported by JUnit 4.

There is still one question left:

Does JUnit 4 really run the methods found from our test class in the correct order?

Let’s move on and find out what happens when we run our unit tests.

Running Our Unit Tests

When we run our unit tests, we should see the following output:

Invoked once before all test methods
Invoked before each test method
Test One
Invoked after each test method
Invoked before each test method
Test Two
Invoked after each test method
Invoked once after all test methods

As we can see, JUnit 4 invokes the methods in the order that was described in this lesson. Let’s summarize what what we learned from this lesson.

Summary

This lesson has taught us four things:

All test classes must be public.

All test methods must be public and must not return anything.

The method annotated with the @Before or @After annotation must be public, must not have any method parameters, and must not return anything.

The method annotated with the @BeforeClass or @AfterClass annotation must be public, must be static static, must not have any method parameters, and must not return anything.