A Java library for capturing log entries in unit and integration tests without mocking or custom extensions.
LogCaptor is a Java library designed to capture log entries for unit and integration testing purposes. It enables developers to verify that their code produces expected log messages, including different log levels, exceptions, and MDC data, without requiring mocking or complex test setup.
Java, Kotlin, and Scala developers writing tests for applications that use logging frameworks like SLF4J, Log4j, or Logback, and need to assert log output as part of their test coverage.
Developers choose LogCaptor because it provides a simple, plug-and-play solution for log testing that works with multiple logging frameworks out of the box, eliminating the need for mocking and reducing test boilerplate.
🎯 LogCaptor captures log entries for unit and integration testing purposes
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Eliminates the need to mock logging frameworks, intercepting actual log messages directly to reduce test boilerplate and improve realism, as highlighted in the README's advantages.
Compatible with SLF4J, Logback, Log4j, Log4j2, Java Util Logging, and Lombok integrations, making it a versatile choice for diverse Java ecosystems, per the Tested Logging libraries section.
Captures not just log messages but also exceptions, MDC data, log levels, and thread details via LogEvent objects, enabling thorough assertions for error handling and context validation.
Can capture logs emitted from different threads within test methods, provided the LogCaptor instance is created locally, useful for testing concurrent applications as noted in the usage examples.
Requires explicit exclusions for multiple SLF4J bindings in build tools like Maven or Gradle, adding setup complexity and potential configuration errors, as admitted in the Known Issues section.
Cannot capture logs from static inner classes with the standard forClass() method when using Log4J2, forcing developers to use workarounds like forName(), which is less intuitive and documented in Known Issues.
Fails in environments with custom classloaders, such as Quarkus tests, where it may not initialize properly, necessitating alternative solutions like ConsoleCaptor and additional configuration overhead.