Unit Testing Best Practices - with Java and Junit Examples


Image Image


Unit Testing is often underrated. As far as I am concerned, having good unit tests seperates good projects from bad. In this article, let’s look at unit testing best practices in depth. We use examples from Java and JUnit to illustrate the concepts. However, the best practices are applicable irrespective of the programming language used.

You will learn

  • What are the benefits of Unit Testing?
  • What is a good unit test?
  • What are examples of Unit Testing Best Practices?
  • How do you write great unit tests?
  • What are the important principles for Unit Testing?

This is fourth article in a series of 4 articles on Automation Testing in Microservices

Free Courses - Learn in 10 Steps

What Is Unit Testing?

By unit testing, we are referring to the xUnit testing (JUnit, NUnit, etc) done on individual code units, such as methods and classes.

Your Attitude Toward Unit Testing

The most important aspect of unit testing is your attitude towards it.

Unit Testing Is More Important Than Code

Unit testing is more important than coding, because it gives you the confidence to carry out continuous refactoring of code. As a result, the overall quality of the low level design improves continuously.

Unit Tests Are Best Written Before Code

The practice of writing unit tests even before you write code is called test driven development (TDD). TDD gives you an outside-in perspective, because you look at code functionality from the perspective of the test. Following TDD improves low level design along with providing with great unit tests.

The Unit Testing Principles

We start with look at generic principles that are applicable to any code, including unit test code. After that we look at principles specific to Unit Tests.

The Four Principles Of Simple Design

Any code, including unit test code, should adhere to Four Principles of Simple Design.

A software application is said to have a simple design if it:

  • Runs all tests
  • Contains no duplication
  • Expresses intent of programmers
  • Minimizes number of classes and methods

Unit Test Specific Principles

Here are some of the important principles which are specific to Unit Tests.

Unit Tests Fail Only when there is a problem with In Production Code

Let’s consider an example where you write a unit test depending on some data in the database. A new developer accidentally changed the data. What would happen? Unit test would fail.

Let’s say it happens again.

The development team would lose confidence in unit tests.

Over a period of time, they would start ignoring tests which are failing.

Unit tests should fail only when there is something wrong with the code. How do we ensure this?

No dependencies between test conditions

Don’t assume the order in which the tests would be run.

JUnit does not guarantee that tests would run in the same order that they are written in.

Avoid External Dependencies

Avoid writing tests that depends on an external database, external interface, a container or a network connection.

If you need to test code functionality that otherwise depends on these, make use of stubs or mock servers.

Avoid Depending On System Date etc

Since the system on which the code will is deployed will be different the development machine, don’t depend on any setup on a machine. Also, avoid hard-coding of system paths within the test code. This will make the test code tied to one machine.

Unit Tests Find All Problems With Production Code

This is the very reason why we test.

  • Test everything that could possibly break. Test exceptions well, and closely test boundary conditions.
  • Try to use strong assertions to detect failures. Do not write tests just for coverage.

Quoting a common JUnit maxim: “Test until fear turns to boredom.”


	becomeTimidAndTestEverything
	whileWritingTheSameThingOverAndOverAgain
		becomeMoreAggressive
		writeFewerTests
		writeTestsForMoreInterestingCases
		ifGetBurnedByStupidDefect
			feelStupid
			becomeTimidAndTestEverything
		end
	End

Remember, this is an infinite loop!

Unit Tests Run Quickly

To maximize benefits, tests should be run as frequently as possible.

If unit tests are slow, they would be run less often.

Avoid reading from the file system, or from the network.

A common solution to test duration is to collect all long-running tests into a single test suite, and run that suite less often.

Unit Tests should be easy to read

Typical tests should not take more than 15 seconds to read.

Here are a couple of examples we use, in explaining Unit Testing standards more effectively:

  • Amount getClientProductsSum(List<Products>):
    • For a list of Products, calculate the sum of Product amounts and return the total.
    • Throw a DifferentCurrenciesException if products have different currencies.
Example-1: Unit Testing Principle - Easy To Understand

	@Test
	public void testClientProductsSum() {
		List<Product> products = new ArrayList<Products>();

		products.add(new ProductImpl(100, "Product 15", ProductType.BANK_GUARANTEE, 
					 new AmountImpl(new BigDecimal("5.0"), Currency.EURO)));
		
		products.add(new ProductImpl(120, "Product 20", ProductType.BANK_GUARANTEE, 
					 new AmountImpl(new BigDecimal("6.0"), Currency.EURO)));

		Amount temp = null;

		try {
			temp. clientBO.getClientProductsSum(products);
		} catch(DirrerentCurrenciesException e) {
			fail();
		}

		assertEquals(Currency.EURO, temp.getCurrency());
	}

This test code is not very readable, isn’t it! The following is another way to write the same test:


	public void testClientProductsSum_AllProductsSameCurrency() throws DifferentCurrenciesException{
		Amount[] amounts = {
			new AmountImpl(new BigDecimal("5.0"), Currency.EURO),
			new AmountImpl(new BigDecimal("6.0"), Currency.EURO)
		};

		List<Product> products = createProductsWithAmounts(amounts);
		Amount actual = clientBO.getClientProductsSum(products);
		Amount expected = new AmountImpl(new BigDecimal("11.0"), Currency.EURO);
		
		assertAmount(actual, expected);
	}

The second version is very easy to understand. The inputs and expectations are clearly states, and this makes it very readable. Teh differences between the two can be summed up in the following points:

Name Of The Test

The name of the test should include the condition being tested and if necessary, the result. hence, testClientProductsSum_AllProductsSameCurrency() is preferrable to testClientProductsSum(). Also, variations such as testClientProductsSum_DifferentCurrenciews_ThrowException() takes on a different condition, and also includes the result. This is preferrable to something mundane such as testClientProductsSum().

The keyword “test” Is Now Superfluous

In later versions of JUnit, after annotations were supported, you don’t need to prefix “test” before every test name. Something like clientProductsSum_DifferentCurrenciews_ThrowException() will do.

Highlight Values Important To A Test

Compare how test setup is being done in the two versions.


	List<Product> products = new ArrayList<Products>();

		products.add(new ProductImpl(100, "Product 15", ProductType.BANK_GUARANTEE, 
					 new AmountImpl(new BigDecimal("5.0"), Currency.EURO)));
		
		products.add(new ProductImpl(120, "Product 20", ProductType.BANK_GUARANTEE, 
					 new AmountImpl(new BigDecimal("6.0"), Currency.EURO)));

Over here, there are a lot of values in the setup code that are not relevant to the test at all, such as 120, "Product 15", ProductType.BANK_GUARANTEE and the like. Compare this to the following in the second example:


	Amount[] amounts = {
			new AmountImpl(new BigDecimal("5.0"), Currency.EURO),
			new AmountImpl(new BigDecimal("6.0"), Currency.EURO)
		};

		List<Product> products = createProductsWithAmounts(amounts);

One the data relevant to the condition being tested are included in the test.

One Condition Per Test

This standard states that:

  • The test results should be presented in simple code without using conditionals, loops, etc.
  • If the test fails, you need to know the exact condition that is failing.
  • Create useful assertion methods to test the specific condition.

	private void assertAmount(Amount expected, Amount actual) {
		assertEquals(expected.getCurrency(), actual.getCurrency());
		assertEquals(expected.getValue(), actual.getValue());
	}

No Exception Handling Within A Test

Have the test method itself throw an exception instead. Prefer the following code:


	public void testClientProductsSum_AllProductsSameCurrency() throws DifferentCurrenciesException{
		//...
	}

Instead of the following:


	//BAD PRACTICE
	try {
			temp. clientBO.getClientProductsSum(products);
		} catch(DirrerentCurrenciesException e) {
			fail();
		}

This keeps the code very readable. If an exception is thrown, the test would fail any way.

Use Annotated Exception Handling To Test For Exceptions

Use code that uses annotated exceptions, such as the following:


	@Test(exception=DifferentCurrenciesException.class)
	public void testClientProductsSum_DifferentCurrencies_ThrowsException() throws DifferentCurrenciesException{
		//... Code That Throws Exception
	}

Avoid code that does things like:


	//BAD CODE WARNING
	@Test
	public void testClientProductsSum1() {
		//...

		try {
			//... Code That Throws Exception
		} catch(DirrerentCurrenciesException e) {
			fail("DifferentCurrenciesException expected");
		}

		//...
	}

If the particular exception is thrown, the annotation detects it, and the test would pass. Otherwise, the test would fail.

Use The New Features

Making use of new features makes code easy to read. Here are a few examples:

  • Comparing arrays: Use assertArrayEquals(expectedArray, actualArray)
  • Testing exceptions: Use <Annotation>(exception=Exception.class)
  • Testing performance: use an annotation like this: <Annotation>(timeout=2). This sets a timeout of 2 milliseconds. The moment the test takes longer to run, it will fail.

Other Unit Testing Best Practices

Unit Tests Should be Separated From Production Code

Unit tests should be organized in separate folders and should not be part of your production deployable unit.

Unit Tests should be included in CI Builds

All unit tests should be run in a CI Build as soon as the code is commited. This leads to early detection of bugs.

You can check out our video on the same topic:

image info

Summary

In this article, we focused on the principles behind writing good unit tests.

If you follows these principles of unit testing, the result is that your tests can be used a documentation. For example, have a look at the tests that we explored a little earlier:

  • testClientProductsSum_AllProductsSameCurrency
  • testClientProductsSum_DifferentCurrencies_ThrowsException
  • testClientProductsSum_NoProducts

These are very readable tests, and they can be used in your business discussions as well!

Related Posts

Docker Tutorial for Beginners - with Java and Spring Boot

Learn about Docker - What is Docker? Why Is Docker Popular? How to create Docker Image for a Java Spring Boot App?

Devops Tutorial | DevOps with Docker, Kubernetes and Azure DevOps

What is DevOps? How is it different from Agile? What are the popular DevOps Tools? What is the role of Docker, Kubernetes and Azure DevOps in DevOps. Let's get started with a simple usecase.

Deploy Java Spring Boot Applications to AWS, Azure, GCP with Docker and Kubernetes

In this article, we focus our attention on the cloud. How to learn the cloud and deploy Java Spring Boot Applications to AWS, Azure, GCP with Docker and Kubernetes?

Spring Boot Tutorials for Beginners

At in28Minutes, we are creating a number of tutorials with videos, articles & courses on Spring Boot for Beginners and Experienced Developers. This resources will help you learn and gain expertise at Spring Boot.

Microservices with Spring Boot and Java - Part 1 - Getting Started

Let's learn the basics of microservices and microservices architectures. We will also start looking at a basic implementation of a microservice with Spring Boot. We will create a couple of microservices and get them to talk to each other using Eureka Naming Server and Ribbon for Client Side Load Balancing. In part 1 of this series, lets get introduced to the concept of microservices and understand how to create great microservices with Spring Boot and Spring Cloud.

20+ Spring Boot Projects with Code Examples

At in28Minutes, we have created more than 20 projects with code examples on Github. We have 50+ articles explaining these projects. These code examples will you learn and gain expertise at Spring Boot.

REST API Best Practices - With Design Examples from Java and Spring Web Services

Designing Great REST API is important to have great microservices. How do you design your REST API? What are the best practices?

Index - 500+ Videos

At in28Minutes, we are creating a number of tutorials with videos, articles & courses on Spring Boot for Beginners and Experienced Developers. Here's a list of video tutorials and courses for you

Creating Spring Boot and React Java Full Stack Application with Maven

This guide helps you create a Java full stack application with all the CRUD (Create, Read, Update and Delete) features using React as Frontend framework and Spring Boot as the backend REST API. We use Maven as the build tool.

Creating a SOAP Web Service with Spring Boot Starter Web Services

Let's learn how to create a SOAP Web Service with Spring Boot Starter Web Services. We will take a Contract First approach by definining an XSD and exposing a WSDL from it.

FREE COURSES



in28Minutes Best Selling Udemy Courses

Image Image Image Image Image Image Image Image Image

450,000 Learners are pursuing our 31 amazing courses and 6 Learning Paths. Start Now!

Join 450,000 Learners and 30+ Amazing Courses

LEARN DEVOPS - 200+ VIDEOS - Master DevOps with Docker, Kubernetes and Azure DevOps


350,000 Learners are learning everyday with our Best Selling Courses : Spring Boot Microservices, Spring, Spring Boot, Web Services, Hibernate, Full Stack React, Full Stack Angular, Python, Spring Interview Guide, Java Interview, Java Functional Programming, AWS, Docker, Kubernetes, PCF, AWS Fargate and Azure


85,000 Subscribers are learning from our Free Videos on YouTube : JSP Servlets, Spring, Spring Boot, Spring MVC, Hibernate, Eclipse, Maven, JUnit, Mockito, Full Stack - React, Full Stack - Angular, Docker, Kubernetes, AWS, AWS Fargate, PCF and Azure


Here are the recommend articles to read next : Spring Interview Questions, Spring Boot Interview Questions, Microservices, Hibernate, Spring Security, REST API with Spring Boot, Full Stack with React, SOAP Web Services, Exception Handling, Embedded Servers, Spring Data Rest, Spring vs Spring MVC vs Spring Boot, Building Web Application and Spring Data JPA.

You can checkout all our 100+ articles here - All Articles.


Do not know where to start your learning journey? Check out our amazing learning paths:
Learning Path 01 - Spring and Spring Boot Web Applications and API Developer,
Learning Path 02 - Full Stack Developer with Spring Boot, React & Angular,
Learning Path 03 - Cloud Microservices Developer with Docker and Kubernetes,
Learning Path 04 - Learn Cloud with Spring Boot, AWS, Azure and PCF and
Learning Path 05 - Learn AWS with Microservices, Docker and Kubernetes


Subscribe