`should equal` fails when `Assert.Equal` doesn't
See original GitHub issueDescription
should equal
fails when Assert.Equal
doesn’t
Repro steps
module SomethingIsWrong
open System.Threading.Tasks
open FSharp.Control.Tasks.V2.ContextInsensitive
open FsUnit.Xunit
open FsUnit.CustomMatchers
open Xunit
[<Fact>]
let test () = task{
let! result = task{
match! Task.FromResult(Error "error") with
| Error error -> return Error error
| Ok _ -> return Ok()
}
// works
result = Error "error" |> should equal true
// works
Assert.Equal(result, Error "error")
// fails
result |> should equal (Error "error")
}
Expected behavior
The test passes
Actual behavior
should equal
fails with “FsUnit.Xunit+MatchException : Exception of type ‘FsUnit.Xunit+MatchException’ was thrown.
Expected: Equals Error “error”
Actual: was Microsoft.FSharp.Core.FSharpResult`2[Microsoft.FSharp.Core.Unit,System.String]”
Related information
- Linux 5.4.2-1-MANJARO
- dotnet sdk 3.1.100
- FsUnit.xUnit 3.8.0
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Assert.AreEqual fails while it shouldn't
Verifies that two specified objects are equal. The assertion fails if the objects are not equal. Verifies that specified object variables refer ...
Read more >Assert.Equal crashes with stack overflow #2271 - xunit/xunit
The fix of this bug is actually very simple: always check object.ReferenceEquals before checking for deep equality. Two objects should always ...
Read more >unit test - AssertEquals not working as expected
It's assertEquals(Any expectedValue, Any actualValue) , but you're putting the "actual value" ( stores.contains(...) ) as the first argument.
Read more >Asserting Equality in your C# unit tests | by Paulo Gomes
By default, the equality operation for those types will only assert whether the two objects being compared are the same, namely your variables...
Read more >Stop requiring only one assertion per unit test
Assertion Roulette doesn't mean that multiple assertions are bad. ... Equal assertion fails, that too will be clear: Assert.Equal() Failure ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I figured it out and have a solution for you.
In your last assertion you may have to add the explicit type to your
Error
, e.g.:result |> should equal (Result<unit, string>.Error "error")
I’m very surprised that the compiler can’t infer the type for this assertion.
I tested it with a simpler example which results in a same way:
The
match
expression is the tie breaker here.I think the
Assert.Equal(result, Result.Error "error")
has an internalbind
to infer the correct type.Edit: Same thing with the equality operator:
(result = Error "error") |> should equal true // works
result.Equals(Error "error") |> should equal true // fails
result.Equals(Result<unit, string>.Error "error") |> should equal true // works
Edit 2: Problem is:
result
from above isResult<unit, string>
and theResult.Error "error"
has only the type ofResult<'a, string>
where'a
is unknown.You may also use the
Result.map
function like this:result |> should equal (Result.Error "error" |> Result.map (fun _ -> ()))
to enforce theunit
type on the left side (Result.Ok ()
).Is it worth it to place this topic into the F# repo as a bug? I think this is a little difficult to decide the compiler does all the work it has no chance to infer the left type.
This is not in FsUnit because you can reproduce this without the FsUnit operators, too.