Our BusinessWorker object will only expose one method. This method will generate a log with the same content for each log level. Although this method isn’t that useful in the real world, it’ll serve well for our testing purposes:

public class BusinessWorker {
    private static Logger LOGGER = LoggerFactory.getLogger(BusinessWorker.class);
    public void generateLogs(String msg) {
        LOGGER.trace(msg);
        LOGGER.debug(msg);
        LOGGER.info(msg);
        LOGGER.warn(msg);
        LOGGER.error(msg);
4. Testing the Logs
We want to generate logs, so let’s create a logback.xml file in the src/test/resources folder. Let’s keep it as simple as possible and redirect all logs to a CONSOLE appender:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <Pattern>
                %d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n
            </Pattern>
        </layout>
    </appender>
    <root level="error">
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>
4.1. MemoryAppender
Now, let’s create a custom appender that keeps logs in memory. We’ll extend the ListAppender<ILoggingEvent> that logback offers, and we’ll enrich it with a few useful methods:
public class MemoryAppender extends ListAppender<ILoggingEvent> {
    public void reset() {
        this.list.clear();
    public boolean contains(String string, Level level) {
        return this.list.stream()
          .anyMatch(event -> event.toString().contains(string)
            && event.getLevel().equals(level));
    public int countEventsForLogger(String loggerName) {
        return (int) this.list.stream()
          .filter(event -> event.getLoggerName().contains(loggerName))
          .count();
    public List<ILoggingEvent> search(String string) {
        return this.list.stream()
          .filter(event -> event.toString().contains(string))
          .collect(Collectors.toList());
    public List<ILoggingEvent> search(String string, Level level) {
        return this.list.stream()
          .filter(event -> event.toString().contains(string)
            && event.getLevel().equals(level))
          .collect(Collectors.toList());
    public int getSize() {
        return this.list.size();
    public List<ILoggingEvent> getLoggedEvents() {
        return Collections.unmodifiableList(this.list);
The MemoryAppender class handles a List that is automatically populated by the logging system.
It exposes a variety of methods in order to cover a wide range of test purposes:

reset() – clears the list
contains(msg, level) – returns true only if the list contains an ILoggingEvent matching the specified content and severity level
countEventForLoggers(loggerName) – returns the number of ILoggingEvent generated by named logger
search(msg) – returns a List of ILoggingEvent matching the specific content
search(msg, level) – returns a List of ILoggingEvent matching the specified content and severity level
getSize() – returns the number of ILoggingEvents
getLoggedEvents() – returns an unmodifiable view of the ILoggingEvent elements
4.2. Unit Test
Next, let’s create a JUnit test for our business worker.
We’ll declare our MemoryAppender as a field and programmatically inject it into the log system. Then, we’ll start the appender.
For our tests, we’ll set the level to DEBUG:
@Before
public void setup() {
    Logger logger = (Logger) LoggerFactory.getLogger(LOGGER_NAME);
    memoryAppender = new MemoryAppender();
    memoryAppender.setContext((LoggerContext) LoggerFactory.getILoggerFactory());
    logger.setLevel(Level.DEBUG);
    logger.addAppender(memoryAppender);
    memoryAppender.start();
Now we can create a simple test where we instantiate our BusinessWorker class and call the generateLogs method. We can then make assertions on the logs that it generates:
@Test
public void test() {
    BusinessWorker worker = new BusinessWorker();
    worker.generateLogs(MSG);
    assertThat(memoryAppender.countEventsForLogger(LOGGER_NAME)).isEqualTo(4);
    assertThat(memoryAppender.search(MSG, Level.INFO).size()).isEqualTo(1);
    assertThat(memoryAppender.contains(MSG, Level.TRACE)).isFalse();
This test uses three features of the MemoryAppender:

Four logs have been generated — one entry per severity should be present, with the trace level filtered
Only one log entry with the content message with the level severity of INFO
No log entry is present with content message and severity TRACE
If we plan to use the same instance of this class inside the same test class when generating a lot of logs, the memory usage will creep up. We can invoke the MemoryAppender.clear() method before each test to free memory and avoid OutOfMemoryException.
In this example, we’ve reduced the scope of the retained logs to the LOGGER_NAME package, which we defined as “com.baeldung.junit.log“. We could potentially retain all logs with LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME), but we should avoid this whenever possible as it can consume a lot of memory.
5. Conclusion
With this tutorial, we’ve demonstrated how to cover log generation in our unit tests.
As always, the code can be found over on GitHub.
Partner – DBSchema – NPI EA (tag = Spring Data JPA)


DbSchema is a super-flexible database designer, which can
take you from designing the DB with your team all the way to
safely deploying the schema.
The way it does all of that is by using a design model, a
database-independent image of the schema, which can be shared in a
team using GIT and compared or deployed on to any database.
And, of course, it can be heavily visual, allowing you to
interact with the database using diagrams, visually compose
queries, explore the data, generate random data, import data or
build HTML5 database reports.
Take a look at DBSchema

Partner – Bellsoft – NPI EA (cat = Spring)


Looking for the ideal Linux distro for running modern Spring
apps in the cloud?
Meet Alpaquita Linux: lightweight, secure, and powerful
enough to handle heavy workloads.
This distro is specifically designed for running Java
apps. It builds upon Alpine and features significant
enhancements to excel in high-density container environments while
meeting enterprise-grade security standards.
Specifically, the container image size is ~30% smaller than
standard options, and it consumes up to 30% less RAM:
Alpaquita Containers now.

Partner – Bellsoft – NPI EA (cat = Spring)


Just published a new writeup on how to run a standard Java/Boot
application as a Docker container, using the Liberica JDK on top of
Alpaquita Linux:
Spring Boot Application on Liberica Runtime Container.

Partner – Aegik AB – NPI EA (tag = SQL)


Slow MySQL query performance is all too common. Of course
it is.
The Jet Profiler was built entirely for MySQL, so it's
fine-tuned for it and does advanced everything with relaly minimal
impact and no server changes.
out the Profiler

Partner – Codium – NPI EA (cat = Testing)


Explore the secure, reliable, and high-performance Test
Execution Cloud built for scale. Right in your IDE:
CodiumAI. Meaningful Code Tests for Busy Devs

Basically, write code that works the way you meant it to.
Partner – Machinet – NPI EA (cat = Testing)


AI is all the rage these days, but for very good reason. The
highly practical coding companion, you'll get the power of
AI-assisted coding and automated unit test generation.

Machinet's Unit Test AI Agent utilizes your own project
context to create meaningful unit tests that intelligently aligns
with the behavior of the code.

Simplify Your Coding Journey with Machinet AI:
>> Install Machinet
AI in your IntelliJ
Course – LS – All

Get started with Spring Boot and with core Spring,
through the Learn Spring course:
>> CHECK OUT THE
COURSE
res – REST with Spring (eBook) (everywhere)

Learning to build your API

with Spring?
Download the E-book