FluentAssertion Should() and Equals() methods shouldn't be used together

[tremblaysimon (Simon Tremblay)]

When writing new unit test using FluentAssertion library, an assertion using Should().Equals(expectedValue) will always return true and the test will always pass. It’s not what is intended since Equals() is inherited from Object and will always return true.

That issue should be categorized as a code smell.

Noncompliant code:

actualValue.Should().Equals(expectedValue);

Compliant code:

actualValue.Should().Be(expectedValue);

or

actualValue.Should().BeEquivalentTo(expectedValue);

---

I think that kind of rule should be valuable for everyone. What do you think?

Thank you,

Simon

[Caba_Sagi (Čaba Šagi)]

Hi @tremblaysimon

Thank you for the suggestion, I like the rule a lot.
In order to be able to implement the rule we first need a rule proposal.

Can you please take a look at this comment with instructions from Nicolas and try to specify it first?

You can also take a look at specification from that issue RSPEC-5770 to see what’s generally needed. In shorthand:

• Name of the rule
• Message
• Proposal of other fields: highlighting (no secondary location in this case). severity, impact,likehood, sonar way?
• Description
• C# Compliant and Noncompliant example (see Sub-Tasks section of the RSPEC)
• VB.NET Compliant and Noncompliant example (see Sub-Tasks section of the RSPEC)

After that we`ll review it and put in in Jira.

[Corniel (Corniel Nobel)]

FluentAssertions has its own analyzer, I would argue that this rule belongs in that analyzer.

[Corniel (Corniel Nobel)]

See: Should().Equals(object) should not be used · Issue #120 · fluentassertions/fluentassertions.analyzers · GitHub