如何用Spock单元测试验证Spring Boot中Logback日志的调用与输出？

Great question! Testing log output is a common need, and there are a couple of solid approaches to do this with Spock and your Lombok-annotated component. Let's start with the most straightforward method using the slf4j-test library, which lets you capture and assert on log events without mocking static fields.

Approach 1: Use SLF4J Test to Capture Logs #

This is the recommended approach—it's clean, simple, and avoids the complexity of mocking static logger fields generated by Lombok.

Step 1: Add the SLF4J Test Dependency #

First, include the slf4j-test library in your build. This replaces the default Logback logger with a test logger that records all log events during your test.

For Maven:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-test</artifactId>
    <version>2.0.9</version> <!-- Use the latest stable version -->
    <scope>test</scope>
</dependency>

For Gradle:

testImplementation 'org.slf4j:slf4j-test:2.0.9'

Step 2: Write the Spock Test #

In your test class, retrieve the TestLogger for your component, invoke the method under test, then assert that the expected log was emitted.

Here's the complete test:

import org.slf4j.LoggerFactory
import org.slf4j.test.TestLogger
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.test.context.SpringBootTest
import spock.lang.Specification

@SpringBootTest
class LogSpec extends Specification {

    @Autowired
    Clazz clazzUnderTest

    TestLogger testLogger = LoggerFactory.getLogger(Clazz) as TestLogger

    def "verify warn log is emitted with message and exception"() {
        when:
        clazzUnderTest.method()

        then:
        // Check that a WARN-level log was recorded
        testLogger.warn().wasCalled()
        // Verify the exact message matches
        testLogger.warn().withMessage("message").wasCalled()
        // Ensure the log includes a RuntimeException
        testLogger.warn().withThrowable(RuntimeException).wasCalled()
    }
}

Key Notes: #

• @SpringBootTest loads the Spring context to autowire your Clazz component. If you don't need the full context, use @ContextConfiguration(classes = Clazz) instead for a lighter unit test.
• The TestLogger provides a fluent API to validate log levels, messages, throwables, and more. You can chain conditions to be as specific as needed.
• Log events are automatically reset after each test, so you don't have to worry about cross-test contamination.

Approach 2: Mock the Static Logger (Using PowerMock) #

If you prefer mocking the static logger generated by Lombok, you can use PowerMock with Spock. This is more complex and adds extra dependencies, so use it only if you have a specific reason not to use slf4j-test.

Step 1: Add PowerMock Dependencies #

Include PowerMock and its Spock integration in your build (check for the latest versions compatible with your Spock and JUnit versions).

Step 2: Write the Test with PowerMock #

import org.powermock.core.classloader.annotations.PrepareForTest
import org.powermock.modules.spock.PowerMockSpecification
import org.slf4j.Logger
import org.slf4j.LoggerFactory
import spock.lang.Specification

@PrepareForTest(Clazz) // Prepare the class with the static logger for mocking
class LogSpec extends PowerMockSpecification {

    Clazz clazzUnderTest = new Clazz()
    Logger mockLogger = Mock(Logger)

    def setup() {
        // Mock the static LoggerFactory.getLogger method to return our mock logger
        PowerMockito.mockStatic(LoggerFactory)
        LoggerFactory.getLogger(Clazz) >> mockLogger
    }

    def "verify warn log is called with message and exception"() {
        when:
        clazzUnderTest.method()

        then:
        // Verify the warn method was called once with the expected arguments
        1 * mockLogger.warn("message", _ as RuntimeException)
    }
}

Key Notes: #

• PowerMock lets you mock static methods like LoggerFactory.getLogger, which is necessary because Lombok generates a static log field in Clazz.
• This approach adds overhead and can make tests slower, so it's not the first choice for most scenarios.

Final Recommendations #

Stick with the slf4j-test approach—it's simpler, more maintainable, and gives you full visibility into log events without the hassle of mocking static fields. It’s the industry standard for testing SLF4J-based logs.

内容的提问来源于stack exchange，提问作者mhuelfen