question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

`should equal` fails when `Assert.Equal` doesn't

See original GitHub issue

Description

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:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
CaptnCodrcommented, Jan 9, 2020

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.

1reaction
CaptnCodrcommented, Jan 14, 2020

I tested it with a simpler example which results in a same way:

let result = 
   match Error "error" with
        | Error error -> Error error 
        | Ok _ -> Ok ()

result |> should equal (Error "error")

The match expression is the tie breaker here.

I think the Assert.Equal(result, Result.Error "error") has an internal bind 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 is Result<unit, string> and the Result.Error "error" has only the type of Result<'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 the unit 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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found