LogAssertions 0.12.0
Prefix Reserveddotnet add package LogAssertions --version 0.12.0
NuGet\Install-Package LogAssertions -Version 0.12.0
<PackageReference Include="LogAssertions" Version="0.12.0" />
<PackageVersion Include="LogAssertions" Version="0.12.0" />
<PackageReference Include="LogAssertions" />
paket add LogAssertions --version 0.12.0
#r "nuget: LogAssertions, 0.12.0"
#:package LogAssertions@0.12.0
#addin nuget:?package=LogAssertions&version=0.12.0
#tool nuget:?package=LogAssertions&version=0.12.0
LogAssertions
Scope: Test projects only. Not intended for production code.
Part of the DotNetAssertions family. This is the framework-agnostic core; the TUnit assertions live in the matching
.TUnitpackage.
Framework-agnostic core for fluent log assertions over Microsoft.Extensions.Logging.Testing.FakeLogCollector.
Most users want
LogAssertions.TUnit, not this package directly. This is the shared engine; framework-specific adapter packages add the assertion entry points your test framework expects.
What's in this package
ILogRecordFilter: composable filter interface (Matches(FakeLogRecord)+Description).LogFilter: static factory for every built-in filter shape (AtLevel,Containing,WithMessageTemplate,WithException,WithoutException(v0.6.0+),WithInnerException(v0.4.0+),WithInnerExceptionMessage(v0.4.0+),WithProperty,WithProperty<T>(v0.6.0+),WithCategory,WithEventId,WithScope,WithScopeProperty,WithScopeProperty<T>(v0.6.0+),WithScopeProperties(v0.4.0+),Matching(LogDefinition)/MatchingCall(LogDefinition)(v0.11.0+),Where, etc.) plus combinators (All,Any,Not).LogDefinition(v0.11.0+): the captured shape of one log call.LogDefinition.Capture(log => LogMessages.OrderShipped(log, 0, ""))invokes the delegate once against a private probe logger and returns a reusable assertion value carrying the event ID, name, template, placeholder values, and exception. Pair withLogFilter.Matching(identity: ID + name + template) orLogFilter.MatchingCall(identity + placeholder values + exception).LogAssertionRendering: failure-snapshot rendering (4-character level abbreviation, props line, scopes line, exception line) withDumpVerbosity-controlled detail level (v0.4.0+:Compact/Default/Verbose). Used by adapter packages and by theDumpToextension below.LogCollectorBuilder.Create(LogLevel): one-line factory returning a wired(ILoggerFactory, FakeLogCollector)tuple.- Inspection extensions on
FakeLogCollector:Filter(params ILogRecordFilter[])returns matching records,CountMatching(params ILogRecordFilter[])returns the count,DumpTo(TextWriter)andDumpTo(TextWriter, DumpVerbosity)(v0.4.0+) write the captured-records snapshot.
Test-framework adapters
| Package | Test framework | Status |
|---|---|---|
LogAssertions.TUnit |
TUnit | Available now |
LogAssertions.NUnit |
NUnit | Possible if there is demand |
LogAssertions.xUnit |
xUnit | Possible if there is demand |
LogAssertions.MSTest |
MSTest | Possible if there is demand |
If you'd find a non-TUnit adapter useful, open a feature request: adapters are not built proactively.
Installation
dotnet add package LogAssertions.TUnit
LogAssertions comes transitively. You don't need to install it directly unless you're building your own adapter package.
Direct use
If you're building a custom adapter or want non-asserting access to filtered records, the public surface lets you compose filters and inspect the collector without going through any test-framework's assertion type:
using LogAssertions;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.Testing;
var (factory, collector) = LogCollectorBuilder.Create();
using (factory)
{
var logger = factory.CreateLogger("MyCategory");
logger.LogWarning("validation failed: TimeoutMs out of range");
// Compose a reusable filter:
ILogRecordFilter validationWarning = LogFilter.All(
LogFilter.AtLevel(LogLevel.Warning),
LogFilter.Containing("validation", StringComparison.Ordinal));
// Inspect without asserting:
int count = collector.CountMatching(validationWarning); // 1
var matches = collector.Filter(validationWarning); // IReadOnlyList<FakeLogRecord>
using var writer = new StringWriter();
collector.DumpTo(writer); // print the captured-records snapshot
}
Building a custom adapter
A test-framework adapter package needs to:
- Reference
LogAssertions. - Provide entry-point methods that surface a fluent chain over the framework's assertion type.
- Use
LogFilterfactory methods to build the filter chain. - Use
LogAssertionRendering.AppendCapturedRecords(...)for failure-message snapshot output (so the format stays consistent across adapters).
LogAssertions.TUnit is the reference implementation: see its source for the pattern.
Stability
- The public surfaces above (
ILogRecordFilter,LogFilter,LogAssertionRendering,LogCollectorBuilder, the extension methods onFakeLogCollector) are semver-bound. Breaking changes require a major version bump. - The exact text format of failure-message snapshots rendered by
LogAssertionRenderingis not stable. May gain extra detail or change formatting in any release. Pin filter match counts and broad markers in tests, not exact failure text.
License
MIT. Copyright (c) 2026 John Verheij.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- Microsoft.Extensions.Diagnostics.Testing (>= 10.7.0)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on LogAssertions:
| Package | Downloads |
|---|---|
|
LogAssertions.TUnit
TUnit-native fluent log-assertion DSL using [AssertionExtension] over Microsoft.Extensions.Logging.Testing.FakeLogCollector. Provides Assert.That(collector).HasLogged()/HasNotLogged() with filter and terminator chaining; emits captured-records snapshot in failure messages. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 0.12.0 | 489 | 7/11/2026 |
| 0.11.0 | 1,418 | 7/11/2026 |
| 0.10.1 | 303 | 6/26/2026 |
| 0.10.0 | 299 | 6/25/2026 |
| 0.9.0 | 195 | 6/15/2026 |
| 0.8.0 | 241 | 6/14/2026 |
| 0.7.0 | 212 | 6/11/2026 |
| 0.6.3 | 173 | 6/6/2026 |
| 0.6.2 | 157 | 6/5/2026 |
| 0.6.1 | 247 | 6/4/2026 |
| 0.6.0 | 159 | 6/2/2026 |
| 0.5.0 | 270 | 5/14/2026 |
| 0.4.1 | 357 | 5/12/2026 |
| 0.4.0 | 187 | 5/7/2026 |
| 0.3.0 | 217 | 5/2/2026 |
| 0.2.4 | 169 | 5/2/2026 |
| 0.2.3 | 146 | 5/1/2026 |
| 0.2.2 | 144 | 5/1/2026 |
| 0.2.1 | 157 | 5/1/2026 |
| 0.2.0 | 136 | 5/1/2026 |
View the rendered release notes: https://github.com/JohnVerheij/LogAssertions.TUnit/releases/tag/v0.12.0
Minor release. Adds the assertion the rest of the DSL was missing: `HasLogged()` and friends assert that an expected record is present, while the new gate asserts that no unexpected one is. Additive; no existing API changed.
### Added
- **`Assert.That(collector).HasLoggedOnly(floor).Allowing(definitions)`** asserts that every captured record at or above `floor` carries the identity of an allowed `[LoggerMessage]` definition. Records below the floor are always permitted and are never enumerated, which is what makes the gate usable on a service whose Debug and Trace volume (heartbeats, request bodies) is large while its warning-and-above band is small enough to list. With no `Allowing(...)` call the gate is the clean-run check: nothing was logged at or above the floor at all. Because it keys on definition identity rather than rendered text, a reworded template cannot slip an unexpected record past it. Assert it once per test class or fixture (a TUnit `[After]` hook over the fixture's collector) rather than per test. When the collector's capture floor sits above the gate's floor the records it claims to inspect were never captured, so the gate fails as vacuous rather than passing for the wrong reason, matching the guard `HasNotLogged()` already had.
- **`MatchingAny(LogDefinition, params LogDefinition[])`** on the assertion chains, and **`LogFilter.MatchingAny(LogDefinition, params LogDefinition[])`** in the framework-agnostic core, filter to records carrying the identity of any of the given definitions. This covers one logical event that is emitted by more than one definition, such as a verbose form that attaches the exception and a terse form that folds the exception text into the message, selected at run time by a flag. There is deliberately no conjunction counterpart: a record carries exactly one identity, so requiring it to match two distinct definitions could never be satisfied.
- **`Step(LogDefinition)`** on `HasLoggedSequence()` adds a strictly-ordered typed step, so a flow reads as one call per event (`.Step(OrderReceived).Step(PaymentCaptured).Step(OrderShipped)`) instead of alternating `Matching(...)` and `Then()`. Further filters chain onto the step just opened.
### Changed
- Documented **where `[LoggerMessage]` definitions must live** to be assertable: `internal` (with `[InternalsVisibleTo]`) or `public`, and **not on a generic type**. Roslynator's `RCS1158` ignores private members, so a private definition on a generic base compiles until it is promoted to `internal` for typed capture, at which point the build breaks; hosting definitions in a non-generic `static partial class` resolves it and reads better at the capture site. Also documented that negative assertions gain the most from typed definitions (a substring `HasNotLogged()` silently passes once the wording drifts; an identity-keyed one cannot), and when to reach for a rendered `LogSnapshotRenderer` snapshot instead.