eBook – Guide Spring Cloud – NPI EA (cat=Spring Cloud)
announcement - icon

Let's get started with a Microservice Architecture with Spring Cloud:

>> Join Pro and download the eBook

eBook – Mockito – NPI EA (tag = Mockito)
announcement - icon

Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.

Get started with mocking and improve your application tests using our Mockito guide:

Download the eBook

eBook – Java Concurrency – NPI EA (cat=Java Concurrency)
announcement - icon

Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.

Get started with understanding multi-threaded applications with our Java Concurrency guide:

>> Download the eBook

eBook – Reactive – NPI EA (cat=Reactive)
announcement - icon

Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:

>> Join Pro and download the eBook

eBook – Java Streams – NPI EA (cat=Java Streams)
announcement - icon

Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.

But these can also be overused and fall into some common pitfalls.

To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:

>> Join Pro and download the eBook

eBook – Jackson – NPI EA (cat=Jackson)
announcement - icon

Do JSON right with Jackson

Download the E-book

eBook – HTTP Client – NPI EA (cat=Http Client-Side)
announcement - icon

Get the most out of the Apache HTTP Client

Download the E-book

eBook – Maven – NPI EA (cat = Maven)
announcement - icon

Get Started with Apache Maven:

Download the E-book

eBook – Persistence – NPI EA (cat=Persistence)
announcement - icon

Working on getting your persistence layer right with Spring?

Explore the eBook

eBook – RwS – NPI EA (cat=Spring MVC)
announcement - icon

Building a REST API with Spring?

Download the E-book

Course – LS – NPI EA (cat=Jackson)
announcement - icon

Get started with Spring and Spring Boot, through the Learn Spring course:

>> LEARN SPRING
Course – RWSB – NPI EA (cat=REST)
announcement - icon

Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:

>> The New “REST With Spring Boot”

Course – LSS – NPI EA (cat=Spring Security)
announcement - icon

Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.

I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.

You can explore the course here:

>> Learn Spring Security

Course – LSD – NPI EA (tag=Spring Data JPA)
announcement - icon

Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.

Get started with Spring Data JPA through the guided reference course:

>> CHECK OUT THE COURSE

Partner – Moderne – NPI EA (cat=Spring Boot)
announcement - icon

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Partner – LambdaTest – NPI EA (cat=Testing)
announcement - icon

Regression testing is an important step in the release process, to ensure that new code doesn't break the existing functionality. As the codebase evolves, we want to run these tests frequently to help catch any issues early on.

The best way to ensure these tests run frequently on an automated basis is, of course, to include them in the CI/CD pipeline. This way, the regression tests will execute automatically whenever we commit code to the repository.

In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:

>> How to Run Selenium Regression Tests With GitHub Actions

Course – LJB – NPI EA (cat = Core Java)
announcement - icon

Code your way through and build up a solid, practical foundation of Java:

>> Learn Java Basics

Partner – LambdaTest – NPI (cat= Testing)
announcement - icon

Regression testing is an important step in the release process, to ensure that new code doesn't break the existing functionality. As the codebase evolves, we want to run these tests frequently to help catch any issues early on.

The best way to ensure these tests run frequently on an automated basis is, of course, to include them in the CI/CD pipeline. This way, the regression tests will execute automatically whenever we commit code to the repository.

In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:

>> How to Run Selenium Regression Tests With GitHub Actions

1. Overview

The standard practice in testing is to rely on test case results, which may pass or fail. However, sometimes we also need to print assertion results. This helps in several cases:

  • Debugging complex test scenarios
  • Monitoring test execution in CI/CD pipelines
  • Creating detailed test reports based on logs

In this article, we’ll review a few approaches to printing assertion results into logs.

2. Assertion Messages With Post-Assertion Logging

The most straightforward and accurate approach is to use well-built assertion messages with post-assertion logic. Let’s create a TestService that we’ll use in our test cases:
public class TestService {
    public boolean successfulCall() {
        return true;
    }

    public boolean failedCall() {
        return false;
    }

    public boolean exceptionCall() {
        throw new RuntimeException("Service error");
    }
}
In this service, we have methods to test passing cases, failing cases, and cases that verify exception-throwing behavior. Now, let’s create TestServiceTest, where we’ll verify TestService. The first test case we create should verify the successful call:
class TestServiceTest {
    private static final Logger logger = LoggerFactory.getLogger(TestServiceTest.class);

    TestService service = new TestService();

    @Test
    void whenSuccessfulCall_thenSuccessMessagePrintedIntoLog() {
        logger.info("Testing successful call...");
        assertTrue(service.successfulCall(), "Service should return true for successful call");
        logger.info("✓ Successful call assertion passed");
    }
}
In this test case, we add info logs before and after the assertion to indicate the assertion passing process. We also add a clear description message in case the assertion fails. After the test passes, we can see the following messages in the logs:
16:21:50.072 [main] INFO com.baeldung.printassertionresults.TestServiceTest -- Testing successful call...
16:21:50.076 [main] INFO com.baeldung.printassertionresults.TestServiceTest -- ✓ Successful call assertion passed
Now, let’s add a test case that will fail:
@Test
void whenFailedCall_thenFailureMessagePrintedIntoLog() {
    logger.info("Testing failed call...");
    assertTrue(service.failedCall(), "Service should return true for failed call");
}
Here, we add logging before the assertion and expect the failure message to appear in the logs.
As expected, the test case does not pass, and here is the log output:

16:26:14.007 [main] INFO com.baeldung.printassertionresults.TestServiceTest -- Testing failed call...
org.opentest4j.AssertionFailedError: Service should return true for failed call

3. Catching Assertion Exceptions

Another approach is to catch the assertion exception and build custom logging around both passing and failing assertions. Let’s start with the creation of an Assertion interface, which we’ll use to wrap our base assertions:
public interface Assertion {
    void doAssert() throws AssertionError;
}
Next, let’s create the AssertionWithMessage class:
public class AssertionWithMessage {
    private final Assertion assertion;
    private final String message;

    public AssertionWithMessage(Assertion assertion, String message) {
        this.assertion = assertion;
        this.message = message;
    }

    public void doAssert() {
        assertion.doAssert();
    }

    public String getMessage() {
        return message;
    }
}
In the doAssert() method, we proxy the call to the real assertion logic. Additionally, we handle the message we want to log during the assertion. Now, let’s create the LoggingAssertions class:
public class LoggingAssertions {
    private static final Logger logger = LoggerFactory.getLogger(LoggingAssertions.class);

    public static void assertAll(AssertionWithMessage... assertions) {
        boolean failed = false;
        for (AssertionWithMessage assertion : assertions) {
            try {
                assertion.doAssert();
                logger.info("✓ {}", assertion.getMessage());
            } catch (AssertionError e) {
                failed = true;
                logger.error("✗ {} - {}", assertion.getMessage(), e.getMessage());
            }
        }

        if (failed) {
            /*
            * Critical: Re-throw to maintain test failure behavior
            * */
            throw new AssertionError("One of the assertions was failed. See logs for details");
        }
    }
}

In the assertAll() method, we run each assertion one by one. If an assertion passes, we log the message with a successful prefix. If an AssertionError occurs, we log the same assertion message with a failing prefix and include the error description. It’s critically important to rethrow the AssertionError if any assertion fails; otherwise, the testing pipeline won’t correctly identify the test cases that need to be fixed.

Now, let’s create the test case where we’ll verify all TestService methods using our LoggingAssertions class:

@Test
void whenRunMultipleAssertionsWithLogging_thenAllTheLogsShouldBePrintedAndFailureExceptionsRethrown() {
    LoggingAssertions.assertAll(
      new AssertionWithMessage(
        () -> assertTrue(service.successfulCall()),
        "Successful call should return true"),
      new AssertionWithMessage(
        () -> assertTrue(service.failedCall()),
        "Failed call should return true"),
      new AssertionWithMessage(
        () -> assertThrows(RuntimeException.class, service::exceptionCall),
        "Exception call should throw RuntimeException")
    );
}

Here, we check all assertions in one shot. As a result, the test case will fail, and the log messages will show the assertion results:

16:44:26.184 [main] INFO com.baeldung.printassertionresults.LoggingAssertions -- ✓ Successful call should return true
16:44:26.187 [main] ERROR com.baeldung.printassertionresults.LoggingAssertions -- ✗ Failed call should return true - expected: <true> but was: <false>
16:44:26.188 [main] INFO com.baeldung.printassertionresults.LoggingAssertions -- ✓ Exception call should throw RuntimeException
java.lang.AssertionError: One of the assertions was failed. See logs for details

4. JUnit 5 Extensions for Test Lifecycle Handling

We can also utilize JUnit 5 extensions to log whether test cases passed or failed. This provides a centralized implementation for test assertion logging. However, this logging works at a higher level than individual assertions. By designing our test cases with one assertion per test, we can still achieve our goal. Let’s create a TestResultLogger class:
public class TestResultLogger implements TestWatcher, BeforeEachCallback {
    private static final Logger logger = LoggerFactory.getLogger(TestResultLogger.class);

    @Override
    public void beforeEach(ExtensionContext context) throws Exception {
        logger.info("Testing {}", context.getDisplayName());
    }

    @Override
    public void testSuccessful(ExtensionContext context) {
        logger.info("✓ {} assertion passed", context.getDisplayName());
    }

    @Override
    public void testFailed(ExtensionContext context, Throwable cause) {
        logger.error("✗ {} assertion didn't pass", context.getDisplayName());
    }
}
Here, we’ve implemented TestWatcher and added logging logic in the testSuccessful and testFailed methods. Additionally, we implemented the BeforeEachCallback interface to add logging before each test. Now, let’s create TestServiceWithTestWatcherTest with the attached TestResultLogger extension:
@ExtendWith(TestResultLogger.class)
class TestServiceWithTestWatcherTest {

    TestService service = new TestService();

    @Test
    void whenSuccessfulCall_thenTrueShouldBeReturned() {
        assertTrue(service.successfulCall());
    }

    @Test
    void whenExceptionCall_thenExpectedExceptionShouldBeThrown() {
        assertThrows(RuntimeException.class, service::exceptionCall);
    }

    @Test
    void whenFailedCall_thenTrueShouldBeReturned() {
        assertTrue(service.failedCall());
    }
}

Here, we’ve implemented multiple test cases, each with a specific assertion to cover all TestService functionality. Here is how the log output looks after the tests are executed:

11:52:53.004 [main] INFO com.baeldung.printassertionresults.TestResultLogger -- Testing whenExceptionCall_thenExpectedExceptionShouldBeThrown()
11:52:53.026 [main] INFO com.baeldung.printassertionresults.TestResultLogger -- ✓ whenExceptionCall_thenExpectedExceptionShouldBeThrown() assertion passed
11:52:53.029 [main] INFO com.baeldung.printassertionresults.TestResultLogger -- Testing whenFailedCall_thenTrueShouldBeReturned()
11:52:53.038 [main] ERROR com.baeldung.printassertionresults.TestResultLogger -- ✗ whenFailedCall_thenTrueShouldBeReturned() assertion didn't pass

org.opentest4j.AssertionFailedError: 
Expected :true
Actual   :false
...
11:52:53.054 [main] INFO com.baeldung.printassertionresults.TestResultLogger -- ✓ whenSuccessfulCall_thenTrueShouldBeReturned() assertion passed

As an advantage of this approach, we achieve clean test case code without additional logic for printing logs inside the test cases.

5. Conclusion

In this article, we’ve reviewed multiple approaches to printing assertion results. We can choose what works best for us. As a baseline, it’s recommended to use clear assertion messages, which cover most cases. For more complex assertion logic, we can build utilities around assertion exception rethrowing. For centralized and easy-to-attach behavior, we can choose to implement logging extensions.
As always, the code is available over on GitHub.
Baeldung Pro – NPI EA (cat = Baeldung)
announcement - icon

Baeldung Pro comes with both absolutely No-Ads as well as finally with Dark Mode, for a clean learning experience:

>> Explore a clean Baeldung

Once the early-adopter seats are all used, the price will go up and stay at $33/year.

eBook – HTTP Client – NPI EA (cat=HTTP Client-Side)
announcement - icon

The Apache HTTP Client is a very robust library, suitable for both simple and advanced use cases when testing HTTP endpoints. Check out our guide covering basic request and response handling, as well as security, cookies, timeouts, and more:

>> Download the eBook

eBook – Java Concurrency – NPI EA (cat=Java Concurrency)
announcement - icon

Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.

Get started with understanding multi-threaded applications with our Java Concurrency guide:

>> Download the eBook

eBook – Java Streams – NPI EA (cat=Java Streams)
announcement - icon

Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.

But these can also be overused and fall into some common pitfalls.

To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:

>> Join Pro and download the eBook

eBook – Persistence – NPI EA (cat=Persistence)
announcement - icon

Working on getting your persistence layer right with Spring?

Explore the eBook

Course – LS – NPI EA (cat=REST)

announcement - icon

Get started with Spring Boot and with core Spring, through the Learn Spring course:

>> CHECK OUT THE COURSE

Partner – Moderne – NPI EA (tag=Refactoring)
announcement - icon

Modern Java teams move fast — but codebases don’t always keep up. Frameworks change, dependencies drift, and tech debt builds until it starts to drag on delivery. OpenRewrite was built to fix that: an open-source refactoring engine that automates repetitive code changes while keeping developer intent intact.

The monthly training series, led by the creators and maintainers of OpenRewrite at Moderne, walks through real-world migrations and modernization patterns. Whether you’re new to recipes or ready to write your own, you’ll learn practical ways to refactor safely and at scale.

If you’ve ever wished refactoring felt as natural — and as fast — as writing code, this is a good place to start.

eBook Jackson – NPI EA – 3 (cat = Jackson)
guest
0 Comments
Oldest
Newest
Inline Feedbacks
View all comments