jsalinaspolo/logcapture

A testing library for asserting logging messages

logcapture's Issues

logcaputre migration guide from 1.2.2 to 1.3.x

Hi,

Is there a migration document to upgrade from 1.2.2 to 1.3.0 for instance? As I am seeing many unrelated tests failing once I update the version.

I am using:

kotlin("jvm") version "1.8.22"
io.kotest version 5.3.1
testImplementation("org.logcapture:logcapture-core:1.2.2")
testImplementation("org.logcapture:logcapture-kotest:1.2.2")

Thanks

Check for X times

Hello there,

First, a big thank you for the library, as it's proving very useful in our test cases.

As stated in the title, is it currently possible to check for the log messages X times, for example, when logging as part of a loop?

I'm going through the source code, but I have not found anything related to this.

Regards

LogCaptureRule should be able to concatenate log assertions

The logged method returns void, so can concatenated logged assertions.

Boolean APIs

@jsalinaspolo
Not sure if this has been raised before, but is there away to have the same APIs but return a boolean instead?

So instead of

logged(aLog().info().withMessage("a message"))

maybe something like

isLogged(aLog().info().withMessage("a message")) == true

The reason is that this will give more flexibility to work with other frameworks like kotest where I can have a precondition like

until(10.seconds) {
    isLogged(aLog().info().withMessage("a message"))
}

Do let me know if this is something we can have or not.

Thanks.

Use ListAppender instead of StubAppender

Hi guys, really cool to see that you all have been working on this. Without knowing of the existence of this project I have built something similar to the core module of this project... Maybe we can share some knowledge to learn from each-others solutions, see here: https://github.com/Hakky54/log-captor

But the main reason why I opened this issue is when I tried to understand the underlying core engine of the logcapture, I see that every log will be added to the Stubappender which is a custom implementation of an appender containing a list. The Stubappender has an additional method called events() which will return the iloggingevents. In this way the logs can be retrieved and asserted. There is already a ListAppender available within Logback, and I am using it in my library, which is capable of doing the same as the Stubappender and much more. So I am wondering why you guys preferred to use a custom Appender instead of the ListAppender. Looking forward to get your thoughts on this topic 😊

Dependency Dashboard

This issue provides visibility into Renovate updates and their statuses. Learn more

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency ch.qos.logback:logback-classic to v1.2.7
• Update dependency gradle to v7.3
• Update plugin org.jetbrains.kotlin.jvm to v1.6.0
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency org.spockframework:spock-core to v2.0-groovy-3.0

---

• Check this box to trigger a request for Renovate to run again on this repository

Add async verify for JUnit Rules

Using the DSL is possible to verify async logs, so using the JUnitRules should be possible as well.

Improve failures matching

Instead of throwing a RuntimeException with the log message not found, would be helpful to display the logs captured.

Build Matchers to assert log messages

Investigate usage of hamcrest matchers or logback custom Filters.

Assert on message using log format

Should support assert on message using the log format replacing {} with the arguments.

Support async logs

Add a way to see a captured log event

Let's say I have something like this in my production code:

var username = "fred";
MDC.put("user", username);
logger.warn("The user " + username + " has requested xyz");

I would like to be able to check that the message contains a string that matches a certain MDC key:

logCaptureListener.logged(aLog().withMdc("user", ???).withMessage(Mathers.containsString(<whatever was in Mdc>));

Perhaps this feature can be delivered in a similar way to Mockito's or Mockk's "capture" facitilities.