Open coolhome opened 3 years ago
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.
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.
I wonder what other imports cause this same problem. If anyone has some knowledge here it might be beneficial for whoever takes this ticket.
Importing FluentAssertions
and not importing FluentAssertions.Json
causes this problem.
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?
@vkhobor I imagine that would work. You should give it a test and let us know :)
@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?
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
, andStringAssertionsExtensions
in theFluentAssertions
namespace? Related to #28