[API Proposal]: Allow custom filtering logic for FakeLogger

[Piedone]

Background and motivation

FakeLogger is useful not just in a unit, but also in an end-to-end/UI testing use case. We also started to use it in our Lombiq UI Testing Toolbox for Orchard Core project.

In this use case, one is looking to run assertions on the log entries. However, when testing a complete app, the log can include entries that we can safely ignore, but these make assertions more complicated. E.g. instead of "the log should be empty" we need to assert "the log should be empty except for entries with the ignored message message".

The best would be to not log these messages in the first place, but in our experience, this is frequently not possible even after applying the existing log filter rules (e.g. filtering out complete classes). We'd need to target specific category-logger-log level-message combinations.

I'd like to propose the ability to optionally configure a custom filter delegate for this. It would work together with the existing filters, AND-ing with them.

API Proposal

public class FakeLogCollectorOptions
{
    /// <summary>
    /// Gets or sets a custom filter predicate for which records are collected.
    /// </summary>
    /// <value>The default is <see langword="null" />.</value>
    /// <remarks>
    /// Defaults to <see langword="null" />, which doesn't filter any records.
    /// If set, only records that the predicate returns <see langword="true" /> for will be collected by the fake logger.
    /// </remarks>
    public Predicate<FakeLogRecord> CustomFilter { get; set; }
}

API Usage

ConfigureLogging(loggingBuilder => loggingBuilder.AddFakeLogging(options =>
{
    options .CustomFilter = record => record.Message != "ignored message";
}))

Alternative Designs

While not an alternative design, a workaround is to adjust the log levels of entries, so they can be filtered on that. However, in our case, due to the log entries coming from external projects that we can't all feasibly change, this is not a suitable solution.

Risks

This is a non-breaking change.

A custom filter predicate, if implemented inefficiently, can potentially slow logging down a lot. Since we're talking only about specific testing scenarios where other filtering is not suitable, I'd consider this acceptable.