Forem: Léa ANDRE

Integration Testing with Failsafe and Merging Reports with JaCoCo in a Spring Boot Project

Léa ANDRE — Thu, 05 Jun 2025 08:07:02 +0000

In one of my recent backend projects built with Spring Boot, I needed to set up a robust testing strategy that included both unit and integration tests. I also wanted a clear view of my overall code coverage, regardless of whether the tests were unit or integration ones.

This article explains how I configured Maven with the failsafe plugin for integration testing and how I merged both unit and integration test coverage reports using jacoco-maven-plugin.

Why Use Failsafe?

By default, Maven’s surefire plugin runs all test classes during the test phase. However, this includes only unit tests. If you run integration tests here, they might fail due to the app not being fully initialized or due to side effects.

The failsafe plugin is designed specifically to run integration tests separately during the integration-test and verify phases, after the application has been properly built and started.

Project Setup

Here’s a simplified overview of the relevant sections in my pom.xml.

Failsafe Plugin

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-failsafe-plugin</artifactId>
  <version>3.0.0-M5</version>
  <executions>
    <execution>
      <goals>
        <goal>integration-test</goal>
        <goal>verify</goal>
      </goals>
    </execution>
  </executions>
</plugin>

This plugin ensures that only test classes following the naming convention *IT.java or *ITCase.java are executed during the integration phase.

JaCoCo Plugin with Merged Reports

I used JaCoCo to generate coverage reports for both unit and integration tests, and then merged them into a single report:

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.8.9</version>
  <executions>

    <!-- For unit tests -->
    <execution>
      <id>pre-unit-tests</id>
      <goals>
        <goal>prepare-agent</goal>
      </goals>
    </execution>

    <execution>
      <id>post-unit-test</id>
      <phase>test</phase>
      <goals>
        <goal>report</goal>
      </goals>
    </execution>

    <!-- For integration tests -->
    <execution>
      <id>pre-integration-tests</id>
      <goals>
        <goal>prepare-agent-integration</goal>
      </goals>
    </execution>

    <execution>
      <id>post-integration-tests</id>
      <phase>post-integration-test</phase>
      <goals>
        <goal>report-integration</goal>
      </goals>
    </execution>

    <!-- Merging reports -->
    <execution>
      <id>merge</id>
      <phase>verify</phase>
      <goals>
        <goal>merge</goal>
      </goals>
      <configuration>
        <fileSets>
          <fileSet implementation="org.apache.maven.shared.model.fileset.FileSet">
            <directory>${project.basedir}</directory>
            <includes>
              <include>**/*.exec</include>
            </includes>
          </fileSet>
        </fileSets>
        <destFile>target/jacoco/allTest.exec</destFile>
      </configuration>
    </execution>

    <!-- Generate final report -->
    <execution>
      <id>post-merge-report</id>
      <phase>verify</phase>
      <goals>
        <goal>report</goal>
      </goals>
      <configuration>
        <dataFile>target/jacoco/allTest.exec</dataFile>
        <outputDirectory>target/jacoco/</outputDirectory>
      </configuration>
    </execution>

  </executions>
</plugin>

This setup generates separate reports for unit and integration tests, merges the .exec data files, and creates a final report at the end of the build in target/jacoco.

How to Run the Tests

To execute both types of tests and generate the final coverage report, run:

mvn clean verify

Unit tests are run during the test phase.
Integration tests are executed in integration-test and verified in verify.
The final coverage report is available in target/jacoco/index.html.

Conclusion

Using Failsafe for integration tests allows you to maintain clean separation between unit and integration tests. Combining it with JaCoCo gives you an accurate view of your test coverage across all types of tests.

This setup has been essential in ensuring my backend remains well-tested and reliable. If you’re building Spring Boot applications with Maven, I highly recommend giving this configuration a try.

Let me know in the comments how you manage your testing strategy or if you have any tips to improve this setup.

Capturing and Testing Logs in Java with SLF4J and Logback: A Simple Guide

Léa ANDRE — Wed, 08 Jan 2025 11:19:26 +0000

When working on Java projects, logging is a vital tool for debugging and understanding application behavior. In some cases, you might want to write tests that verify specific log messages are produced under certain conditions. Here’s a simple guide to achieving that using SLF4J with Logback and a custom TestLogAppender.

Setting Up the Example

We’ll create a basic service that logs an error when an exception occurs, and a corresponding test to verify the log message.

Step 1: Add Logback Test Dependency

...
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <scope>test</scope>
</dependency>
...

Step 2: Implementing the Service

Here’s a simple service that catches exceptions and logs an error:

package com.example.loggingdemo;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class SimpleService {
    private static final Logger logger = LoggerFactory.getLogger(SimpleService.class);

    public void performTask() {
        try {
            // Simulate some task that fails
            throw new IllegalArgumentException("Simulated exception");
        } catch (IllegalArgumentException e) {
            logger.error("An error occurred: {}", e.getMessage());
        }
    }
}

Step 3: Creating a Custom TestLogAppender

This appender captures log messages during tests, enabling assertions on their content.

package com.example.loggingdemo;

import ch.qos.logback.classic.spi.ILoggingEvent;
import ch.qos.logback.core.AppenderBase;

public class TestLogAppender extends AppenderBase<ILoggingEvent> {
    private final StringBuilder logs = new StringBuilder();

    @Override
    protected void append(ILoggingEvent eventObject) {
        logs.append(eventObject.getFormattedMessage()).append("
");
    }

    public String getLogs() {
        return logs.toString();
    }
}

Step 4: Writing the Test

Now, let’s write a test to verify the log output.

package com.example.loggingdemo;

import static org.assertj.core.api.Assertions.assertThat;

import ch.qos.logback.classic.Logger;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.slf4j.LoggerFactory;

public class SimpleServiceTest {
    private TestLogAppender logAppender;
    private SimpleService simpleService;

    @BeforeEach
    public void setup() {
        // Attach TestLogAppender to the logger
        logAppender = new TestLogAppender();
        logAppender.start();
        Logger logger = (Logger) LoggerFactory.getLogger(SimpleService.class);
        logger.addAppender(logAppender);

        // Initialize the service
        simpleService = new SimpleService();
    }

    @Test
    public void testPerformTaskLogsError() {
        // Act
        simpleService.performTask();

        // Assert
        String logs = logAppender.getLogs();
        assertThat(logs).contains("An error occurred: Simulated exception");
    }
}

Important
Don't forget to start your log appender !

Step 5: Running the Test

When you run this test, it will confirm that the SimpleService logs the expected error message when an exception occurs.

How It Works

Custom Appender: The TestLogAppender captures log messages by overriding the append method of Logback’s AppenderBase.
Logger Configuration: During tests, we dynamically attach the custom appender to the target logger.
Assertions on Logs: Use the captured logs for assertions in your tests, verifying specific messages or patterns.

Conclusion

With this approach, you can confidently test your logging behavior, ensuring your application logs important events and errors as expected. This setup is versatile and can be adapted to more complex scenarios, such as testing log levels or message formatting.

Feel free to try this out and adapt it to your own projects!

Happy coding!