Unit testing with Java frameworks: JUnit and TestNG [Tutorial]

Frequent manual testing is too impractical for any but the smallest systems. The only way around this is the use of automated tests. Automated tests are an effective method to reduce the time and cost of building, deploying, and maintaining applications. In order to effectively manage applications, it is of the utmost importance that both the implementation and test codes are as simple as possible.

In this tutorial, we will look at implementing simple and easy to learn Java Unit testing frameworks for writing and running test i.e. JUnit and TestNG.

You are reading Java unit testing tutorial from the book Test Driven Java Development - Second Edition, written by Alex Garcia and Viktor Farcic.

What is Unit testing?

Unit testing is a practice that forces us to test small, individual, and isolated units of code. They are usually methods, even though in some cases classes or even whole applications can be considered to be units, as well. In order to write unit tests, code under tests needs to be isolated from the rest of the application. Preferably, that isolation is already ingrained in the code or it can be accomplished with the use of mocks.

If unit tests of a particular method cross the boundaries of that unit, then they become integration tests. As such, it becomes less clear what is under the tests. In case of a failure, the scope of a problem suddenly increases and finding the cause becomes more tedious.

Java Unit testing frameworks

In this section, two of the most used Java frameworks for unit testing are shown and briefly commented on. We will focus on their syntax and main features by comparing a test class written using both JUnit and TestNG. Although there are slight differences, both frameworks offer the most commonly used functionalities, and the main difference is how tests are executed and organized.

Let's start with a question. What is a test? How can we define it?

In the programming approach, there are several types of tests depending on their scope—functional tests, acceptance tests, and unit tests. Further on, we will explore each of those types of tests in more detail. Let's see how to test a single Java class. The class is quite simple, but enough for our interest:

public class Friendships { 
  private final Map<String, List<String>> friendships = 
     new HashMap<>(); 
 
  public void makeFriends(String person1, String person2) { 
    addFriend(person1, person2); 
    addFriend(person2, person1); 
  } 
 
  public List<String> getFriendsList(String person) { 
    if (!friendships.containsKey(person)) { 
      return Collections.emptyList(); 
    } 
    return friendships.get(person)
  } 
 
  public boolean areFriends(String person1, String person2) { 
    return friendships.containsKey(person1) &&  
        friendships.get(person1).contains(person2); 
  } 
 
  private void addFriend(String person, String friend) { 
    if (!friendships.containsKey(person)) { 
      friendships.put(person, new ArrayList<String>()); 
    } 
    List<String> friends = friendships.get(person); 
    if (!friends.contains(friend)) { 
      friends.add(friend); 
    } 
  } 
}

Testing with JUnit

JUnit is a simple and easy-to-learn framework for writing and running tests. Each test is mapped as a method, and each method should represent a specific known scenario in which a part of our code will be executed. The code verification is made by comparing the expected output or behavior with the actual output.

The following is the test class written with JUnit. There are some scenarios missing, but for now we are interested in showing what tests look like. We will focus on better ways to test our code and on best practices later in this book.

Test classes usually consist of three stages: set up, test, and tear down. Let's start with methods that set up data needed for tests. A setup can be performed on a class or method level:

Friendships friendships; 
 
@BeforeClass 
public static void beforeClass() { 
  // This method will be executed once on initialization time 
} 
 
@Before 
public void before() { 
  friendships = new Friendships(); 
  friendships.makeFriends("Joe",",," "Audrey"); 
  friendships.makeFriends("Joe", "Peter"); 
  friendships.makeFriends("Joe", "Michael"); 
  friendships.makeFriends("Joe", "Britney"); 
  friendships.makeFriends("Joe", "Paul"); 
}

The @BeforeClass annotation specifies a method that will be run once before any of the test methods in the class. It is a useful way to do some general set up that will be used by most (if not all) tests.

The @Before annotation specifies a method that will be run before each test method. We can use it to set up test data without worrying that the tests that are run afterwards will change the state of that data. In the preceding example, we're instantiating the Friendships class and adding five sample entries to the Friendships list. No matter what changes will be performed by each individual test, this data will be recreated over and over until all the tests are performed.

Common examples of usage of those two annotations are the setting up of database data, the creation of files needed for tests, and so on. Later on, we'll see how external dependencies can and should be avoided using mocks. Nevertheless, functional or integration tests might still need those dependencies and the @Before and @BeforeClass annotations are a good way to set them up.

Once the data is set up, we can proceed with the actual tests:

@Test 
public void alexDoesNotHaveFriends() { 
  Assert.assertTrue("Alex does not have friends", 
     friendships.getFriendsList("Alex").isEmpty()); 
} 
 
@Test 
public void joeHas5Friends() { 
  Assert.assertEquals("Joe has 5 friends", 5, 
     friendships.getFriendsList("Joe").size()); 
} 
 
@Test 
public void joeIsFriendWithEveryone() { 
  List<String> friendsOfJoe =  
    Arrays.asList("Audrey", "Peter", "Michael", "Britney", "Paul"); 
  Assert.assertTrue(friendships.getFriendsList("Joe")
     .containsAll(friendsOfJoe)); 
}

In this example, we are using a few of the many different types of asserts. We're confirming that Alex does not have any friends, while Joe is a very popular guy with five friends (Audrey, Peter, Michael, Britney, and Paul).

Finally, once the tests are finished, we might need to perform some cleanup:

@AfterClass 
public static void afterClass() { 
  // This method will be executed once when all test are executed 
} 
 
@After 
public void after() { 
  // This method will be executed once after each test execution 
}

In our example, in the Friendships class, we have no need to clean up anything. If there were such a need, those two annotations would provide that feature. They work in a similar fashion to the @Before and @BeforeClass annotations. @AfterClass is run once all tests are finished. The @After annotation is executed after each test. This runs each test method as a separate class instance. As long as we are avoiding global variables and external resources, such as databases and APIs, each test is isolated from the others. Whatever was done in one, does not affect the rest.

The complete source code can be found in the FriendshipsTest class at https://bitbucket.org/vfarcic/tdd-java-ch02-example-junit.

Testing with TestNG

In TestNG, tests are organized in classes, just as in the case of JUnit.

The following Gradle configuration (build.gradle) is required in order to run TestNG tests:

dependencies { 
   testCompile group: 'org.testng', name: 'testng', version: '6.8.21' 
} 
 
test.useTestNG() { 
// Optionally you can filter which tests are executed using 
//    exclude/include filters 
// excludeGroups 'complex' 
}

Unlike JUnit, TestNG requires additional Gradle configuration that tells it to use TestNG to run tests.

The following test class is written with TestNG and is a reflection of what we did earlier with JUnit. Repeated imports and other boring parts are omitted with the intention of focusing on the relevant parts:

@BeforeClass 
public static void beforeClass() { 
  // This method will be executed once on initialization time 
} 
 
@BeforeMethod 
public void before() { 
  friendships = new Friendships(); 
  friendships.makeFriends("Joe", "Audrey"); 
  friendships.makeFriends("Joe", "Peter"); 
  friendships.makeFriends("Joe", "Michael"); 
  friendships.makeFriends("Joe", "Britney"); 
  friendships.makeFriends("Joe", "Paul"); 
}

You probably already noticed the similarities between JUnit and TestNG. Both are using annotations to specify what the purposes of certain methods are. Besides different names (@Beforeclass versus @BeforeMethod), there is no difference between the two. However, unlike Junit, TestNG reuses the same test class instance for all test methods. This means that the test methods are not isolated by default, so more care is needed in the before and after methods.

Asserts are very similar as well:

public void alexDoesNotHaveFriends() { 
  Assert.assertTrue(friendships.getFriendsList("Alex").isEmpty(), 
      "Alex does not have friends"); 
} 

public void joeHas5Friends() { 
  Assert.assertEquals(friendships.getFriendsList("Joe").size(), 
      5, "Joe has 5 friends"); 
} 

public void joeIsFriendWithEveryone() { 
  List<String> friendsOfJoe = 
    Arrays.asList("Audrey", "Peter", "Michael", "Britney", "Paul");
  Assert.assertTrue(friendships.getFriendsList("Joe")
      .containsAll(friendsOfJoe)); 
}

The only notable difference when compared with JUnit is the order of the assert variables. While the JUnit assert's order of arguments is optional message, expected values, and actual values, TestNG's order is an actual value, expected value, and optional message. Besides the difference in the order of arguments we're passing to the assert methods, there are almost no differences between JUnit and TestNG.

You might have noticed that @Test is missing. TestNG allows us to set it on the class level and thus convert all public methods into tests.

The @After annotations are also very similar. The only notable difference is the TestNG @AfterMethod annotation that acts in the same way as the JUnit @After annotation.

As you can see, the syntax is pretty similar. Tests are organized in to classes and test verifications are made using assertions. That is not to say that there are no more important differences between those two frameworks; we'll see some of them throughout this book. I invite you to explore JUnit and TestNG by yourself.

The complete source code with the preceding examples are here.

The assertions we have written until now have used only the testing frameworks. However, there are some test utilities that can help us make them nicer and more readable.

To summarize, we learned about JUnit and Test NG; the Java unit testing frameworks. We also ran tests on both the frameworks to know the usage and difference between the two.

To learn concepts of test-driven development in Java to help you build clean, maintainable and robust code, check out this book Test Driven Java Development - Second Edition.

Unit Testing Apps with Android Studio

Unit Testing in .NET Core with Visual Studio 2017 for better code quality