DEV Community: Alex Rabelo Ferreira

Create fast integration tests

Alex Rabelo Ferreira — Sat, 09 Aug 2025 02:45:55 +0000

The developers need to create tests to achieve better quality for systems. There are some challenges to creating tests. The developers need to know the libraries and frameworks for testing. The company needs to create an environment like production. Using Testcontainers, you can create an environment similar to production. It increases the difficulty of creating tests and can increase the pipeline time. One solution for that is to create tests only for system slices and not for the entire system. This article shows how Spring helps us to create these types of tests.

Spring Tests

Tests are one part of development that is difficult for a lot of developers. The developers need to know the library and frameworks to run the tests. The libraries help to integrate the language and the framework. The framework web mocks the dependencies for each infrastructure. So the developers tend to skip the test phase due to these challenges. Spring-Boot came to help with libraries, such as the spring-boot-tests library. The library helps developers create simple tests faster.

Slices tests on Spring Boot

The first Spring-Boot versions only help to create integration tests. These tests set up all the configurations of the system with Spring and waste a lot of time on pipelines. Also, it wastes a lot of computer resources to run. So, Spring-Boot 2.4 added Slices tests in the testing library. This type of test configures specific layers of an application, like the web layer (MVC layer).

It does not configure the database and other infrastructures. So, the test uses fewer resources and runs faster than conventional Spring tests. Also, since the first version, the community has added new Slice Tests. The last added was for Cassandra databases.

Slice tests Types

There are a lot of slice tests on the Spring Boot Test library. The list of types is in the official document. The main types are:

MockMVC tests for Web applications
JPATest for repository
AMQPTest for listeners/senders

MockMVC Tests The Mock

McvTest will start in the Spring only for the web application layer. It won't configure the database or other beans to test this layer. An example of a controller test is below:

@ContextConfiguration(classes = {SpringApplicationLight.class})
@Import({JacksonAutoConfiguration.class, LoggerBeanFactory.class, ResourceExceptionHandler.class})
@WebMvcTest(AuthorizationResource.class)
class AuthorizationResourceIT {

    private final CreateAuthorizationRequest request = RequestFixtures.createAuthorizationRequest();

    @Autowired MockMvc mockMvc;
    @Autowired ObjectMapper objectMapper;

    @MockBean CreateAuthorization useCase;

    private final String baseUrl = "/authorizations";

    @Test
    void shouldReturn200_whenRequestIsValid() throws Exception {
        String authorizationId = "authorizationId";
        ArgumentCaptor<CreateAuthorizationInput> captor = ArgumentCaptor.forClass(CreateAuthorizationInput.class);
        Mockito.when(useCase.execute(captor.capture())).thenReturn(authorizationId);

        mockMvc.perform(post(baseUrl).contentType(MediaType.APPLICATION_JSON)
                        .content(objectMapper.writeValueAsString(request))).andDo(MockMvcResultHandlers.print())
                .andExpect(status().is2xxSuccessful())
                .andExpect(jsonPath("$.authorizationId").value(authorizationId))
        ;

    }

This code uses mockMvc to create a server with the controller. It creates an object of your controller configured by the @WebMvcTest annotation. After Junit initialization, Spring creates an object to inject into the field mockMvc.

The object will create an HTTP server that receives a request and calls the controller. So, in the test method, MockMvc handles the request to the controller object.

The controller will process the request and return a response object. After, MockMvc will return to us the response to make assertions. We can use MockMvc to assert the status, the body content, and others with expected values.

JPA Tests

Repository tests require a database infrastructure. There is more than one repository per system. We need to create a base class shared between all the repository tests. One example is:

@ActiveProfiles("db")
@DataMongoTest(excludeAutoConfiguration = {
        EmbeddedMongoAutoConfiguration.class,
})
@AutoConfigureDataJpa
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
public class BaseRepositoryIT {

    private static final DynamicPropertyConfigurableContainer noSqlContainer = new CustomNoSqlContainer();
    private static final DynamicPropertyConfigurableContainer sqlContainer = new CustomDataBaseContainer();

    @DynamicPropertySource
    static void datasourceProperties(DynamicPropertyRegistry dynamicPropertyRegistry) {
        noSqlContainer.configure(dynamicPropertyRegistry);
        sqlContainer.configure(dynamicPropertyRegistry);
    }

}

This is a JPA-based class. We need this base class to create the containers to serve as databases. This is a way to create a lot of repository tests with the same setup.

The class is using two libraries, one for NoSQL and the other for SQL. The DataMongoTest annotation sets up the NoSQL beans. You can use embedded Mongo. We are using the Testcontainers library to create containers for us. So, we exclude the embedded configuration.

We did the same for SQL. The annotation AutoConfigureTestDatabase removes the embedded database. After that, you can set up the properties from each container to Spring properties. Use the DynamicPropertySource annotation to set properties for each database. The Spring needs the port from the container to connect to the databases. We used the dynamic properties to set the ports.

Now, we can create all the repository tests extending from this base class. An example of tests for the repository can be:


class AuthorizationRepositoryIT extends BaseRepositoryIT {

    @Autowired AuthorizationRepository repository;

    private final Authorization authorization = DomainFixtures.createAuthorization();

    @Test

    void shouldSaveAuthorization() {
        Authorization savedAuth = repository.save(authorization);
        assertNotNull(repository.findById(savedAuth.id).orElseThrow());
    }

}

This test uses the repository to save an entity. The database created by TestContainers is the database container. The base configuration doesn't create any other bean. The controllers, HTTP clients, and other types are not created.

Rest client test

You can test REST requests too. One way is to use the Wiremock library. It creates a web server to mock some api. The component tests will call the client REST. Wiremock will mock the request and response of the client. You can generate any response to each scenario that you want to test. The Wiremock can be set up on a container or started a server manually. You only need to set the Spring properties for the API port with the Wiremock server port.

The API client tests are like repository tests. It is common to have more than one client per system. All these tests can share the same configurations. So, we can create a base class to share these configurations among all the client tests.

You can configure Wiremock using a server object or a container. The first option permits you to make more flexible requests and response mocks. The container option helps you to prepare the local test infrastructure. This option keeps the mapping files updated. One change to the API contract will break the component tests. So, in this example, we are using a container to set up Wiremock. We need to create all the files to simulate different scenarios for the tests.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {
        FeignAutoConfiguration.class,
        FiegnConfiguration.class,
})
@EnableFeignClients
public class BaseContainerClientTest {

    private static final DynamicPropertyConfigurableContainer WIREMOCK_CONTAINER = new CustomWiremockContainer();

    @DynamicPropertySource
    static void datasourceProperties(DynamicPropertyRegistry dynamicPropertyRegistry) {
        WIREMOCK_CONTAINER.configure(dynamicPropertyRegistry);
    }
}

The annotations used above the Base class name are to set up the dependencies common to all clients. You can reuse a container using a static field to create the container. The Testcontainers will keep the container alive until the JVM shuts down. The method implemented set up the properties related to the container. The dynamic properties object will set up the properties for your APIs.

Once you have a base class, you can create a test class for each client. The class needs to extend the base class. The methods use a similar logic. It calls the client method that will make an HTTP request to the WireMock server. The WireMock will return a response. Then the method can assert on the response object.

class GitHubClientTest extends BaseContainerClientTest {

    @Autowired 
     private ClientExample client;

    @Test
   voidshouldThrowErrorWhenClientReturn500() {
       FeignException feignException = Assertions.assertThrows(FeignException.class, () -> client.getRepo("id-to-500"));
       Assertions.assertEquals(500, feignException.status());
    }

    @Test
   voidshouldThrowErrorWhenClientReturn400() {
       FeignException feignException = Assertions.assertThrows(FeignException.class, () -> client.getRepo("id-to-400"));
       Assertions.assertEquals(400, feignException.status());
    }

    @Test
   voidshouldReturnOkWhenClientReturnResponse() {
       FeignException feignException = Assertions.assertThrows(FeignException.class, () -> client.getRepo("id-to-200"));
       Assertions.assertEquals(200, feignException.status());
    }
}

There is a disadvantage to using containers instead of the WireMock server bean. You need to create a response mock in an external directory. It needs to be accessible by the container at runtime. So, you need to re-run the test after updating the mock file. Also, we cannot create two different behaviors for a get method without parameters or headers. In cases where there are many GET methods, use the Wiremock bean instead of the container.

The advantage of using static files is in the development environment. The developers can run the application locally using a Docker Compose file. The tests confirm all the mocks. So, if the developer needs to simulate some scenario for a PRD bug, they can set some values in the mock files. Also, they need to run the Wiremock container to debug the PRD scenario.

But there are some scenarios that the file mapping don't cover. You can use Wiremock server bean to solve this problem. Wiremock bean is an object that the developer can change the mock stubs programatically. The developer can reuse the stubs created for container base class. The base class for this type of test will be as below:

  @ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {
       FeignAutoConfiguration.class,
        FiegnConfiguration.class,
})
@EnableFeignClients
public classBaseServerClientTest {

    private static finalWireMockConfiguration config= WireMockConfiguration.wireMockConfig()
          .usingFilesUnderDirectory("docker");
    protected staticWireMockServer wiremockServer= newWireMockServer(config);

     @DynamicPropertySource
   static voiddatasourceProperties(DynamicPropertyRegistry dynamicPropertyRegistry) {
       wiremockServer.start();
        dynamicPropertyRegistry.add("wiremock-host", wiremockServer::baseUrl);
    }
}

The class is similar to other base class in the Spring annotations. The main difference is on Wiremock server field that use a config object. You need to use this config to set the directory of yours stubs mapping files to reuse of them. Finally, you need to set the environment variable with the base url from Wiremock server.

The test is the same when using file to stub. The difference now is how to stub. You need to use wiremock server variable to create stub. You have more power to create stub. You can change the return without parameters, you can simulate to return any HTTP response.

classGitHubClientTest extendsBaseServerClientTest {

     @Autowired
   privateGitHubClient client;

    @Test
   voidshouldThrowErrorWhenClientReturn500() {
       FeignException feignException = Assertions.assertThrows(FeignException.class, () -> client.getRepo("id-to-500"));
       Assertions.assertEquals(500, feignException.status());
    }

    @Test
    voidshouldThrowErrorWhenClientReturn400() {
        FeignException feignException = Assertions.assertThrows(FeignException.class, () -> client.getRepo("id-to-400"));
       Assertions.assertEquals(400, feignException.status());
    }

    @Test
    voidshouldReturnOkWhenClientReturnResponse() {
        GitResponse response = client.getRepo("id-to-200");
        Assertions.assertEquals("repo-test", response.repo);
    }

    @Test
    voidshouldReturnOkWhenClientReturnAllResponse() throwsJSONException {
       JSONObject jsonObject = newJSONObject();
       jsonObject.put("repo", "test");
       wiremockServer.stubFor(
              WireMock.get(WireMock.urlEqualTo("/git"))
                    .willReturn(WireMock.okJson(jsonObject.toString()))
        );

       GitResponse response = client.getRepo();
        Assertions.assertEquals("test", response.repo);
    }
}
    class GitHubClientTest extends BaseServerClientTest {

    @Autowired
    private GitHubClient client;

    @Test
    void shouldThrowErrorWhenClientReturn500() {
        FeignException feignException = Assertions.assertThrows(FeignException.class, () -> client.getRepo("id-to-500"));
        Assertions.assertEquals(500, feignException.status());
    }

    @Test
    void shouldThrowErrorWhenClientReturn400() {
        FeignException feignException = Assertions.assertThrows(FeignException.class, () -> client.getRepo("id-to-400"));
        Assertions.assertEquals(400, feignException.status());
    }

    @Test
    void shouldReturnOkWhenClientReturnResponse() {
        GitResponse response = client.getRepo("id-to-200");
        Assertions.assertEquals("repo-test", response.repo);
    }

    @Test
    void shouldReturnOkWhenClientReturnAllResponse() throws JSONException {
        JSONObject jsonObject = new JSONObject();
        jsonObject.put("repo", "test");
        wiremockServer.stubFor(
                WireMock.get(WireMock.urlEqualTo("/git"))
                        .willReturn(WireMock.okJson(jsonObject.toString()))
        );

        GitResponse response = client.getRepo();
        Assertions.assertEquals("test", response.repo);
    }
}

Using bean, you can create stubs for different scenarios; you have more power. However, the local environment can not use these stubs. So, prefer to use success scenarios with file stubs.

Conclusion

In this article, we showed how to create integration tests with fewer resources. We showed the power of tests by layers with the Spring Boot framework. You can talk more about tests, call me. You have a special chance to book on my calendly this week. It will be a pleasure to help you solve your problem.

High System quality with Spring integration tests

Alex Rabelo Ferreira — Fri, 29 Dec 2023 00:01:08 +0000

A developer deals with a lot of activities by day. One of which is deploying a production application. They need to ensure the quality to deploy in production. They create a pipeline to run a set of automated tests to hold the quality. This article helps Java developers create automated tests. So you will learn how to create integration tests using Spring. If you want to use Quarkus, see this article for Quarkus. First, we will show how to create the base classes for our tests. Next, we will show how to run an application using platforms managed by a library. Finally, we will create an integration test example.

Using a web platform Spring

A web system needs some platforms to work. A database is the first and the second can be a cache. A back-end developer needs to set up all these platforms to test the local system. The fastest way use the docker to run a container to each platform. Using docker compose you can run all the containers by one command. So, using docker and docker compose you can run the web system in seconds. But, when the developer needs to create integration tests, the docker-compose is not enough. In this article, we will show how to create containers for tests using a library.

Creating infrastructure with Docker

Docker is a tool that can help the developer to run each dependency in containers. Find more about Docker at Docker Official.

Provisioning with TestContainers library

The library TestContainers creates all the environments for your tests. The library starts all containers for each platform before the test starts to run. It permits you to create any type of container using codes. You can set a lot of container configurations. You can set ports, networks, and the container's version. Find more information at TestContainers quick start. The first step is to create a base class to create the containers. First of all, you need to add the library to your dependency management. In Gradle, you can do that:

testImplementation "org.junit.jupiter:junit-jupiter:5.8.1"
testImplementation "org.testcontainers:testcontainers:1.17.2"
testImplementation "org.testcontainers:junit-jupiter:1.17.2"

Container class

The container class is a class that extends the GenericContainer class. This class is inside the TestContainers library and has a lot of methods to set up a container. The class needs to have a constructor that receives the image name and the version of the container. Each platform required by the application needs a container class. For example, databases, message brokers, and caches, each need a container class. There are already some container classes inside the library as known databases. But, if you need a specific configuration, you need to create a new class.

Creating a integration test

The integration test is a test that runs the application with all the dependencies. The test can be a simple test that runs a method or a test that runs a complete flow of the application. So, the developer needs to create a test that uses the web platform to simulate the real environment. After creating the container classes, you can create a base integration class. You will use this class to set up all your test changes in one place.

Base test class

A base class will create all the containers and set up the connection configurations. For example, you can see below a Java class example for Spring:

@SpringBootTest
@ActiveProfiles("test")
public class IntegrationTest {

        @Container
        public static final PostgreSQLContainer<?> POSTGRES_CONTAINER = new PostgreSQLContainer<>("postgres:13.2");

        @Container
        public static final RedisContainer<?> REDIS_CONTAINER = new RedisContainer<>("redis:6.2.1");

        @DynamicPropertySource
        static void postgresProperties(DynamicPropertyRegistry registry) {
            registry.add("spring.datasource.url", POSTGRES_CONTAINER::getJdbcUrl);
            registry.add("spring.datasource.username", POSTGRES_CONTAINER::getUsername);
            registry.add("spring.datasource.password", POSTGRES_CONTAINER::getPassword);
        }

        @DynamicPropertySource
        static void redisProperties(DynamicPropertyRegistry registry) {
            registry.add("spring.redis.host", REDIS_CONTAINER::getHost);
            registry.add("spring.redis.port", REDIS_CONTAINER::getFirstMappedPort);
        }
}

You need to configure in this class each platform that your application uses. You configure a database and Redis cache platforms for example. An important thing to notice is the static container field. The TestContainers library uses the same container for all the tests. The library creates a singleton container. After that, you can create your integration test class. The example below shows how to create an integration test class for a Spring application:

public class UserRepositoryIT extends IntegrationTest {

    @Autowired
    private UserRepository userRepository;

    @Test
    public void shouldCreateUser() {
        User user = new User("Alex");
        userRepository.save(user);
        assertThat(userRepository.findById(user.getId())).isPresent();
    }
}

You will see the containers created by the TestContainers after running the tests. The Spring will replace the connection configuration for the database. After, Spring will create the repository bean using the correct database connection. So, the test can use the repository to assert the result for each scenario.

Environment

Github host this example. The versions used are the following:

Junit: 5
TestContainers: 1.17.6
Java 11
Spring boot: 2.5.6

Conclusion

In this article, we showed how to create integration tests with the Spring framework. We use the TestContainers library to create all platforms required by the application. The community created a lot of repositories to share binds to other languages. See more in the TestContainers's Github account. If you like this content and want to talk more about a problem, call me. You have a special chance to book on my calendly this week. It will be a pleasure to help you solve your problem.

Stop suffering with tests, use TestContainers

Alex Rabelo Ferreira — Thu, 02 Feb 2023 21:56:25 +0000

Developers need to work with two or more systems during the workday. The quality of these systems depends on the integration and unit tests. It requires a pipeline and a big infrastructure. The pipeline run tests in a server similar to the production server called staging. According to [1,2], the cost to maintain a server is 2k to 15k in production. It is a high cost depending on the company. The cost duplicates when needs an environment for production and another for staging. But a pipeline that runs tests in a staging environment can result in a lot of false positive errors when a dependent system is down or a team is deploying a new version. Also, a developer team can lead to other problems, the high platform amount to install, the difference between platforms' versions per developer, the difficulty to update the platform version, and the difference between platforms' versions in production and developer environments.

A rest API system needs at least one database and a message broker system. But a real market system needs a cache service, and storage system and the list of platforms can increase a lot according to market requirements. So, to run locally the system, a developer needs to install all that platforms. The number can increase exponentially when has more systems. The developer needs to install different versions of each platform to each system. Another problem is that a developer can install a platform with version x and another developer install version z. The first developer can create a test that works in the version x, but doesn't work in version z. So, the second developer can not run the tests and require help to discover the error because of the difference in the versions. A similar problem is when a bug happens in production and don't happen locally because of difference in the versions. In addition, when a new developer tries to set up the developer environment, the code cloned doesn't have the version of the platforms. So, he needs to install the lasted version available to run the tests. The end of history is that a lot of tests will fail and in the worst case he won't run the system locally without the help of a senior developer.

This article is to help developers to waste less money and to continue increasing the system delivery quality. We will show how can use two tools, Docker and TestContainers to decrease the cost to test systems with Java. Use Docker to provide the infrastructure to your dependencies and the TestContainers is a library that permits you to create different scenarios for your tests. Therefore, the reader will learn how to use these tools to create your test environment easily, having the lowest cost and working without difficulties with a developer team.

Creating infrastructure with Docker

All software needs some infrastructure like a database or a message broker. The basic process for a developer to test the software in the development stage is manually creating the environment in your workstation. Docker is a tool that can help the developer to run each dependency in containers. Find more about Docker at Docker Official.

Provisioning with TestContainers library

The library TestContainers make it easy to create all the environments for your tests at the start of the test platform. It permits you to create any type of container programmatically. You can set the ports, the networks, version of the containers and can set the correct configuration for each test. Find more information at TestContainers quick start.

Using Test Containers

First of all, you need to add the library to your dependency management. In Gradle you can do that:

testImplementation "org.junit.jupiter:junit-jupiter:5.8.1"
testImplementation "org.testcontainers:testcontainers:1.17.2"
testImplementation "org.testcontainers:junit-jupiter:1.17.2"

There are two modes to set up containers in your tests, shared container, and local container. The first type is to create and stop the container only when JVM stops and the second is to create a new container for each method test. But in both modes, you create a container for your test starting from the creation of a class to your container or set up a library that creates a container for you. You can see below an example to create a container class for Postgres:

public class CustomPostgresContainer extends PostgreSQLContainer<CustomPostgresContainer> {

   public CustomPostgresContainer() {
      super(DockerImageName.parse("postgres:13-alpine").asCompatibleSubstituteFor("postgres"));
      withUsername("postgres");
      withPassword("<password>");
      withDatabaseName("<db-name>");
      withExposedPorts(5432);

      start();
   }
}

After that, you can create a container for your test using this class. An observation here is the need for a new dependency that has the class PostgreSQLContainer:

testImplementation 'org.testcontainers:postgresql:1.17.6'

Now look at an example test using that class:


public class ExampleRestIT extends IntegrationTest {

   private CustomPostgresContainer postgresContainer = new CustomPostgresContainer();

   @Test public void shouldStartingAContainer() {
      postgresContainer.start();

      Assertions.assertTrue(postgresContainer.isRunning());
   }
}

This scenario is to have control of the container. There is an annotation that will inform to TestContainers what container needs to be started and stopped for each method test. You can see an example below:

@Testcontainers
public class ExampleRestIT extends IntegrationTest {

   @Container
   private CustomPostgresContainer postgresContainer = new CustomPostgresContainer();

   @Test public void shouldStartingAContainer() {
      // postgresContainer.start(); ------ Dont need any more

      Assertions.assertTrue(postgresContainer.isRunning());
   }
}

Using a web platform

But this is a test without any web platform like Quarkus or Spring. A setup of TestContainers to Quarkus for example needs some new classes. But, before we need to understand our requirements. Depending on your scenario, you will need to start and stop a container for each class of tests. In another case, you can reuse one container for all tests. For the first case, create a class that implements a QuarkusTestResourceLifecycleManager. For example the class below:

public class SharedContainerResource implements QuarkusTestResourceLifecycleManager {
    protected CustomPostgresContainer POSTGRES_CONTAINER = new CustomPostgresContainer();

    @Override
    public Map<String, String> start() {
        return POSTGRES_CONTAINER.configureProperties();
    }

    @Override
    public void stop() {
        POSTGRES_CONTAINER.stop();
    }
}

With this class, you can control the creation and destruction of a container. When the Quarkus context starts, it will create the container. After, it will call the method start to get all the properties to replace these values. For example, the port to connect to the Postgres database. When the Quarkus context stops, call the method stop and we can stop the container. If we don't need a new container for each test class, you can remove the stop function and create a static field like these:

public class SharedContainerResource implements QuarkusTestResourceLifecycleManager {
    protected static final CustomPostgresContainer POSTGRES_CONTAINER = new CustomPostgresContainer();

    @Override
    public Map<String, String> start() {
        return POSTGRES_CONTAINER.configureProperties();
    }

    @Override
    public void stop() {
        // removed the stop function of the container. The TestContainer library will destroy automatically when the JVM stops
    }
}

With that configuration, we can create a container to the context, and at the end of execution, the TestContainer library will automatically stop the container. We recommend this feature for scenarios where you have independent tests and don't need new infrastructure, like a clean database. Using this mode you can waste less time running the tests than using a local container.

You can find more details in TestContainers quick start from the official documentation.

Environment

We used the following versions:

TestContainers: 1.17.2
Gradle: 6
Docker: 20
Quarkus: 1.13.6.Final
Java: 11

This example code is in this repository.

Conclusion

In this article, we show how to create integration tests with containers to simulate any kind of environment. We also show the two modes of setting up the containers in your tests and the differences between them. Also, we gave examples to use the library TestContainers with the Quarkus platform.

However, in this article, we did not cover how to use TestContainers with other web platforms like Spring. In Addition, more libraries integrate with Docker in other languages. The community created a lot of repositories in the TestContainers's GitHub account to share binds to other languages.

If you like this content and want to talk more about a problem that you are facing in your day aligned with tests, you have a special chance to book on my calendly this week. It will be a pleasure to help you solve your problem.

Don't discover bugs in production, use unit tests

Alex Rabelo Ferreira — Thu, 31 Mar 2022 23:53:13 +0000

A bug in software development is common, but some times it can cost a lot. The most known case of a bug that cost million of dollars was the Mariner 1 spacecraft. An investigation revealed the cause. A very simple software error, the developer omitted an hyphen in a line of code. That sent an incorrect guidance signals to the spacecraft. The cost of the omission turned out to be more than $18 million at the time (about $169 million in today’s currency).

So, don't lose money discovering bugs in production. Prevent it with a simple method, use tests in the development stage. Here you will learn one type of test for Java projects, and how to create and run them in during development. At the end, you will be ready to configure your project with tests. Use libraries, plan the scenarios and create the tests and mocks. Finally, you will prevent bugs in production.

Prevent bugs with Unit Test

The most simple test is unit test. It need to be simple and test only one
scenario in isolated way.

Mock

In a unit test, the main goal is to test some behavior from one unit (a class in Java). A mock is a way to create a object that the unit that you are testing depends on. So, If you are testing a Class called ExportToJsonService and this class depends on a another class called FileService, you can test the ExportToJsonService without instantiate the real FileService implementation, you can use some library to create a Mock of FileService. The mock will be a object of FileService, but without any implementation of the behaviors from the real implementation.

Create a unit test

Now, you know about unit test and mocks. Before starting creating a tests, we need libraries to don't reinvent the wheel. There are two Java libraries that can help you to create unit tests in JAVA:

Junit
EasyMock

The first one is a platform that help a java developer to create tests and run in a JVM. The second is a library that help you to isolate the test creating mocks for you. In the next sessions, you will learn how to use theses libraries in development proccess. In the end, you will find the full example of a project with theses libraries in a github repository.

Project example

So, let define some project to exemplify the use of the java test libraries. This project is simple, it generates a PDF certificate to participants of an event. So, there are two features in this project:

Generate a certificate in PDF format
Generate a certificate metada in JSON format

So, we designed the project to have these classes:

GenerateCertificate

public class GenerateCertificate {

    private final ExportService pdfExportService;
    private final ExportService jsonExportService;

    public GenerateCertificate(ExportService pdfExportService, ExportService jsonExportService) {
        this.pdfExportService = pdfExportService;
        this.jsonExportService = jsonExportService;
    }

    public void generateCertificate(CertificateData certificateData) {
        // Generate Object Certificate from data
        // Export a PDF file from certificate object
        // Export a Json metadata from certificate object
    }

}

ExportService

public interface ExportService {

    void export(Certificate certificate);

}

Planning your tests

The creation of tests start from the scenarios that you need to test. There are two types of scenarios:

Success when the input are correct
Error when the input are incorrect

So, the first test of GenerateCertificate is when the CertificateData is enough to generate a Certificate objetct that
can be exported in PDF and in JSON. Moreover, the second test is when there is something in the CertificateData that
lead to a error when try to create a certificate object.

Therefore, the first test is when the certificate object passed to exportService instance are correct and the two
instances of the exportService is called.

First unit test

After plan the test, develop it with Junit and EasyMock. We can create a Test with Junit 5 with a Class that
had @Test above a method. So, the method annotated is the first scenario.

GenerateCertificateTest

import org.junit.jupiter.api.Test;


public class GenerateCertificateTest {

    @Test
    public void whenGenerateCertificate_withCertificateDataValid_thenExportCertificate() {

    }
}

We created a test for the unit. Now we need to create a instance of our unit: GenerateCertificate. After, we need to call the
method to test our scenario inside the method of the test with the correct inputs:

import dev.alexferreira.testtechniques.example.certificate.model.Certificate;
import dev.alexferreira.testtechniques.example.certificate.model.CertificateData;
import dev.alexferreira.testtechniques.example.certificate.service.ExportService;
import org.easymock.*;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

class GenerateCertificateTest {

    private final GenerateCertificate generateCertificate;

    @Test
    void whenGenerateCertificate_withCertificateDataValid_thenExportCertificate() {
        CertificateData certificateData = new CertificateData();
        generateCertificate.generateCertificate(certificateData);
    }
}

After, We use the EasyMock library to create mocks and call's verification. So, we can create a scenario to test some code flux. See the example above:

import dev.alexferreira.testtechniques.example.certificate.model.Certificate;
import dev.alexferreira.testtechniques.example.certificate.model.CertificateData;
import dev.alexferreira.testtechniques.example.certificate.service.ExportService;
import org.easymock.*;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

@ExtendWith(EasyMockExtension.class)
class GenerateCertificateTest extends EasyMockSupport {

    /*01**/
    @Mock
    /*02**/ private ExportService exportService;
    /*03**/
    /*04**/
    @TestSubject
    /*05**/ private final GenerateCertificate generateCertificate = new GenerateCertificate(null);

    /*06**/
    /*07**/
    @Test
    /*08**/    void whenGenerateCertificate_withCertificateDataValid_thenExportCertificate() {
        /*09**/
        exportService.exportPDFFile(EasyMock.anyObject(Certificate.class));
        /*10**/
        replayAll();
        /*11**/
        /*12**/
        CertificateData certificateData = new CertificateData();
        /*13**/
        generateCertificate.generateCertificate(certificateData);
        /*14**/
        /*15**/
        verifyAll();
    }
}

Test detailed

Let's analyse the test:

line 1 - 2: define a mock exportService. The annotation specific to create an instance without any behavior.
line 4: create a instance of the unit and inject the mocks.
line 5: define the object to test and inject the mocks
line 7-16: define the block to test and Junit execute it
line 10: call replayAll to specify for EasyMock the mocks to verify after that point.
line 15: call verifyAll to configure EasyMock to verify all calls in all mocks created. It will throw an error when some call are not expected.

The test will verify the calls to generateCertificate. If exportPDFFile() was not called, the test will fail.

Therefore, the EasyMock will help you to validate the unit dependencies behaviors. You can see more features from EasyMock at the official documentation.

Running a test

So, at this point, we can run the test with maven: mvn test or with gradle: gradlew test. The test will fail, because we did not implement the function like the test expect. According to Test driven development (TDD), we should implement the unit in a cyclic process. You need run test, implement/fix and run test. So, the implementation is incomplete until the test had passed. Find more information about TDD here.

Versions used in this example

The example used in theses tutorial is hosted
by Github. The versions used are following:

Junit: 5
EasyMock: 4.3
Java 11

Conclusion

We presented how to prevents bugs with unit tests, the libraries that you can use to create the tests and mocks. Now you can prevent bug in production.

We used two libraries that are enough for a developer create unit tests to his software. But, you need to pay attention to the versions and the compatibility between them. There are another libraries, but this article is not comparing them. We is showing one example of library for each requirements to create tests.

I am a Java Developer that help another Java developers to apply tests techniques in software development, so they deliver stable features faster without break things.