SerilogSinksInMemory Versions Save

• Add assertions for verifying properties on messages that have a property that contains a destructured object
• Switched builds from AppVeyor to Github Actions

Serilog.Sinks.InMemory 0.7.0

• Introduce InMemorySinkSnapshot for testing (see below).
• Change target frameworks for test projects to net462, netcoreapp3.1 and net6.0

Serilog.Sinks.InMemory.Assertions: 0.9.1

• Use the new snapshot mechanism from InMemorySink instead of using reflection to achieve that.

This release introduces support for FluentAssertions 6.x and maintains backwards compatibility with FluentAssertions 5.x releases. A test project has been added to verify this compatibility, see Serilog.Sinks.InMemory.Assertions.Tests.Unit.FluentAssertions6

This release also:

• Upgrades xUnit to 2.4.1 and xUnit VS runner to 2.4.3
• Upgrades Serilog to 2.10.0
• Formats the LogEventLevel values so that they are always presented in assertion messages as "Information". This is to ensure the assertions show consistent behaviour when using FluentAssertions 5 or 6
• Adds netcoreapp3.1 as a test target
• Removes netcoreapp2.0 as a test target as it's no longer supported

This release fixes two issues and introduces a new assertions that let you verify the values of a property on multiple instances of the same message.

Issues fixed in this release:

• #15
• #16
• #17

Thanks to @rafek1241, @yaroshvitaly and @xavierjohn for the reports :+1:

This release of the assertions package introduces the WhichValue<T> method that provides a more direct way to access the value of the log property. That allows you to use other assertions such as HaveLength or BeLessThan on the value.

This release adds a few new assertions that help with checking whether messages exist or not, adds support for patterns in messages and cleans up the way that references of the packages are created.

An overview of the new assertion options:

Asserting on a pattern in a message:

InMemorySink.Instance
   .Should()
   .HaveMessage()
   .Containing("some pattern")
   .Appearing().Once();

which will match test some pattern message.

Assert that any message has been logged:

InMemorySink.Instance
   .Should()
   .HaveMessage()
   .Appearing().Times(3);

Assert that no messages have been logged:

InMemorySink.Instance
   .Should()
   .NotHaveMessage();

Assert that a specific message has not been logged:

InMemorySink.Instance
   .Should()
   .NotHaveMessage("some message");

This release merges PR #9 from @Lokdei which now allows you to configure a log level on the sink to control which messages will be collected by the in-memory sink.

The packages had a dependency on a very specific version of FluentAssertions, that caused issues when you were using the sink in a project that had a newer version of FluentAssertions than was expected by Serilog.Sinks.InMemory.Assertions. So with this release you probably don't have to spend hours trying to figure out why you're getting a MissingMethodException when calling Should().HaveMessage("....")

This version aligns the set-up of the sink more with other Serilog sinks. Instead of WriteTo.InMemorySink() which had the redundant "Sink" in the name you can now do WriteTo.InMemory().

Also to make the usage in tests a bit cleaner you can now use the static Instance property of InMemorySink to get the current instance used. That means you can simply do WriteTo.InMemory() and access the sink using InMemorySink.Instance. The property is backed by an AsyncLocal<T> variable so it's safe for multi-threaded tests.

Example of the new test usage:

public void GivenFoo_BarHappens()
{
    var logger = new LoggingConfiguration()
        .WriteTo.InMemory()
        .CreateLogger();

    logger.Information("foo");

    InMemorySink.Instance
        .Should()
        .HaveMessage("foo");
}

No more local variable declaration, yay!

This signifies the first public release of the in-memory sink for Serilog and the associated FluentAssertions helpers.

I invite you to test this release and provide feedback in the issues with everything you like or think that could be better in the API or the documentation.

I'll happily accept PRs if you have an improvement you would like to see included.