Repository navigation
Error message generation does not work very well for throw cases #871
Description
Description
When testing that some code should throw an exception the generated error message is not very helpful (especially when using .And).
Complete minimal example reproducing the issue
[Test]
public void Test ()
{
// ACT
Action act = () => SomeAction();
// ASSERT
act.Should().Throw<SomeException>().And.Property.Should().Be("Value");
}Actual behavior:
The resulting error message is:
Expected act to be "Value" with length of 5, but "<actualValue>" has a length of <actualLength>.
The current error message is not helpful in several ways:
- The error message completely ignores the
.Andand does not mention the actual property (Property) - "act" does not represent the called method very well, but this might be very hard to fix
The second part might be very hard (or even impossible to fix), but the first part is very annoying and probably not only affects exception assertions but all kinds of assertions that use .And, although I suspect that it mostly occurs in conjunction with exception assertions (at least in our code that is the only time we use .And).
Expected behavior:
I would expect a message something like this:
Expected Exception.Property to be "Value" with length of 5, but "<actualValue>" has a length of <actualLength>.
Versions
We are using Fluent Assertions v5.3.0 with .NET Framework 4.7.1.
Additional Information
There is a way to work-around this issue (var exception = act.Should().Throw<Exception>().And;) but it feels pretty weird to assign an .And to a variable. In general I think the .And syntax does not work very well with exception assertions.
Activity
jnyrup commentedon Jul 25, 2018
A complete minimal example would be
Running the same example in Fluent Assertions 4.19.4 will give you
So even though the approach in v5 isn't perfect it is an improvement over v4.
We're doing textual extraction to try to locate the caller, see CallerIdentifier.DetermineCallerIdentity()
E.g. this perfectly valid C# code
gives you:
One can always write complex formatted, nested or chained assertions, that we will fail to extract correctly with the textual extraction approach,
Where by correctly, I mean the sub-assertion that causes the combined assertion to fail.
thomaslevesque commentedon Aug 11, 2019
I just noticed this issue with a similar example from the documentation:
This produces the following message:
This is misleading, since it doesn't properly identify the subject.
I realize that it's not possible to cover all cases, but it would be nice if it worked at least for chained assertions.