Problem Statement
Throws<AggregateException>() currently allows asserting the outer exception, but it does not provide a fluent way to continue into AggregateException.InnerExceptions. TUnit already has the assertion pieces needed after that point, such
as collection assertions, All().Satisfy(...), IsTypeOf<T>(), and WithParameterName(...), but users must first break the chain, capture the thrown exception in a local variable, and then start a second assertion on
exception.InnerExceptions.
In practice, this makes aggregate exception assertions noticeably less fluent than single-inner-exception assertions, which already have a dedicated WithInnerException() path. The gap is especially visible when asserting that all inner
exceptions are of a specific exception type and share the same parameter name or message characteristics. The API surface already supports these checks once the collection is available; the missing piece is a first-class bridge from
Throws<AggregateException>() to InnerExceptions.
Proposed Solution
It would be smoother if this could be written as:
await Assert.That(someDelegate)
.Throws<AggregateException>()
.WithInnerExceptions()
.Count().IsEqualTo(3);
Alternatives Considered
I've tried to use Member(), but that is not available on ExceptionAssertions.
So what works now is the following:
AggregateException exception = (await Assert.That(createBlueprint)
.Throws<AggregateException>())!;
await Assert.That(exception.InnerExceptions)
.Count().IsEqualTo(3));
Feature Category
Assertions
How important is this feature to you?
Nice to have - would improve my experience
Additional Context
No response
Contribution
Problem Statement
Throws<AggregateException>()currently allows asserting the outer exception, but it does not provide a fluent way to continue into AggregateException.InnerExceptions. TUnit already has the assertion pieces needed after that point, suchas collection assertions,
All().Satisfy(...), IsTypeOf<T>(), andWithParameterName(...), but users must first break the chain, capture the thrown exception in a local variable, and then start a second assertion onexception.InnerExceptions.In practice, this makes aggregate exception assertions noticeably less fluent than single-inner-exception assertions, which already have a dedicated
WithInnerException()path. The gap is especially visible when asserting that all innerexceptions are of a specific exception type and share the same parameter name or message characteristics. The API surface already supports these checks once the collection is available; the missing piece is a first-class bridge from
Throws<AggregateException>()toInnerExceptions.Proposed Solution
It would be smoother if this could be written as:
Alternatives Considered
I've tried to use
Member(), but that is not available on ExceptionAssertions.So what works now is the following:
Feature Category
Assertions
How important is this feature to you?
Nice to have - would improve my experience
Additional Context
No response
Contribution