Reduce friction on importing FluentAssertions.Json idea

[coolhome]

To reduce false positives and improve user experience with someJToken.Should().BeEquivalentTo(expectedJToken) I was thinking a Roselyn Analyzer can be used to suggest a code fix.

public AndConstraint<TAssertions> BeEquivalentTo<TExpectation>(TExpectation expectation, string because = "", params object[] becauseArgs)

I imagine we can find all references to this where TAssertions and TExpectation are JToken/JObject/JArray/JValue and suggest a code fix to import FluentAssertions.Json.

I think another approach could be to move JsonAssertionExtensions, ObjectAssertionsExtensions, and StringAssertionsExtensions in the FluentAssertions namespace? Related to #28

[dennisdoomen]

As we don't want to have Fluent Assertions take a dependency on NewtownSoft.Json, we decided to have a separate package, this repository. But a Roslyn analyzer could work. But unless somebody from the community is willing to assist here, we don't have to time to build one.

[akamud]

I like this idea, in my team we had so many false positives and it took so long for people to find them that we ended up creating wrappers to make sure we are always using the FluentAssertions.Json method.

An analyzer would be perfect indeed.

[coolhome]

I wonder what other imports cause this same problem. If anyone has some knowledge here it might be beneficial for whoever takes this ticket.

[dennisdoomen]

Importing FluentAssertions and not importing FluentAssertions.Json causes this problem.

[vkhobor]

Hi. In the meantime, if I just put FluentAssertions.Json into the test package as a global using that would eliminate false positives all together?

[coolhome]

@vkhobor I imagine that would work. You should give it a test and let us know :)

[vkhobor]

@vkhobor I imagine that would work. You should give it a test and let us know :)

Will do. 👍🏻
Is there a documented test case that I can use to produce a false positive? When does this occur?