FsUnit.Xunit : when using result type, on error, actual message is not showing the pretty printing but type info.

[cboudereau]

Description

When the unit test "should equal" failed, an error message indicates the pretty printing for the Expected but only type info the the Actual one.

Repro steps

1. Add the FsUnit.Xunit

2. add a unit test with :
   Ok "hello" |> should equal (Ok "world")

Expected behavior

Expected result :

FsUnit.Xunit+MatchException: Exception of type 'FsUnit.Xunit+MatchException' was thrown.
Expected: Equals Ok "world"
Actual:  Equals Ok "hello"

Actual behavior

FsUnit.Xunit+MatchException: Exception of type 'FsUnit.Xunit+MatchException' was thrown.
Expected: Equals Ok "world"
Actual:   was Microsoft.FSharp.Core.FSharpResult`2[System.String,System.Object]
   at FsUnit.Xunit.Assert.That.Static[a](a actual, IMatcher`1 matcher) in /Users/sergey/github/FsUnit/src/FsUnit.Xunit/FsUnit.fs:line 19
   at FsUnitBench.AssertBug.result bug() in C:\gh\UnitTestingBenchmark\FsUnitBench\AssertBug.fs:line 9

Known workarounds

let private pretty x = sprintf "%A" x

let shouldBe (expected:'a) (actual:'a) = 
    if expected <> actual then 
        raise (Xunit.Sdk.EqualException(pretty expected, pretty actual))

Related information

• Operating system
• Branch
• .NET Runtime, CoreCLR or Mono Version
• Performance information, links to performance testing scripts

[sergey-tihon]

I think the investigation should start here
https://github.com/fsprojects/FsUnit/blob/master/src/FsUnit.Xunit/FsUnit.fs#L18
and check how DescribeMismatch is implemented in https://github.com/nhamcrest/NHamcrest

[CaptnCodr]

I looked where the message "was ..." come from. This is when I stringify the actual value.

The Result type string "Microsoft.FSharp.Core.FSharpResult`2[System.String,System.Object]" comes from when it's parsed through the CLR from F# to C# and gets stringified from C# code like here: https://github.com/nhamcrest/NHamcrest/blob/master/src/NHamcrest/Core/Matcher.cs#L11.

I played around and got the solution which @cboudereau wrote down in "Known workarounds".

It's an ugly parsing message from NHamcrest isn't it?

@sergey-tihon When's ok then I would like to open a PR that basic implements the actual value as string without going the detour through NHamcrest.

[CaptnCodr]

It possibly go right when NHamcrest has a F# version of the matcher. But NHamcrest wasn't updated for a long time so far.
It would also be good when there is a matcher that is based on the actual running .NET core.

NHamcrest has actually TargetFramework netstandard1.5;net451 (https://github.com/nhamcrest/NHamcrest/blob/master/src/NHamcrest/NHamcrest.csproj#L4)

[CaptnCodr]

I opened a PR #155 which will fix the "ugly" message.
Xunit and MsTest messages were affected.

[CaptnCodr]

Fixed with #155.