ReceivedCallsException despite the expected and actual calls being identical.

[hgirma]

ReceivedCallsException despite the expected and actual calls being identical.

[dtchepak]

Hi @hgirma ,

Is equality implemented for this type? Or is it using reference equality?
e.g. if you new up two instances and Assert.That(a, Is.EqualTo(b)) does it pass when NSubstitute is not involved?

[hgirma]

Hi @dtchepak

No it does not, I created a sample repo to reproduce the issue

https://github.com/hgirma/WebApplication2

similar setup work with other types in my codebase and without IEquatable implemented.

[Ergamon]

I also waited for an example, because I expected the same. Many of our junior developers make the same mistake. We humans always think that 2 objects having the same information must be the same. Sadly that is not what .NET does. If you dont change anything about your objects, then Equals only returns true if they are the same object.

This has nothing to do with NSubstitute, but is how .NET works:

      // Assert
      user.Should().Be(user);
      transaction.Should().Be(new Transaction
      {
        Amount = -shopItem.Amount,
        CreatedBy = user.Id,
        CurrencyId = shopItem.CostCurrencyTypeId,
        CurrencyType = shopItem.CostCurrencyType,
        Note = $"Redeemed: {shopItem.Description}",
        UserId = user.Id,
        OpportunityType = "Redeem",
        TransactionKind = TransactionKind.Shop,
        CreatedDate = _timeProvider.GetUtcNow().LocalDateTime,
        IsDeleted = false,
      });

This is basically the same test and fails exactly the same way.

There are many ways to solve this:

• Write a predicate comparing property for property, like you did in your working test
• Let your classes implement IEquitable, basically overriding Equals
• Use records where the SourceGenerator does this for you
• Combine NSubstitute with FluentAssertions and use BeEquivalentTo instead of Be

[hgirma]

yep, junior mistake :) I went with predicate for now...