Improve possibility to exclude certain fields from comparaison

[dstj]

Hi,

I'm using FluentAssertions.Json in a functional test to validate the response from an access token creation endpoint. Obviously, the returned access_token JSON property varies from test to test, but I'd like to to use FluentAssertions.Json to compare everything else. I'd like to do something like:

var actual = JObject.Parse(responseString);

var expectedOtherFields = JObject.Parse(@"{
  ""token_type"":""Bearer"",
  ""expires_in"":3600
}");
actual.Should().BeEquivalentTo(expectedOthers, options => options.ExcludingMissingMembers());

// manual comparaison of actual["access_token"].Value<string>() with a regex

or this signature may be more versatile:

actual.Should().BeEquivalentTo(expectedOthers, options => options.Excluding(new[] { <paths to exclude> }));

Right now, I have to do remove the access_token property from the response before comparing the other fields:

var jwtProperty = actual.Children<JProperty>().SingleOrDefault(x => x.Name == "access_token");
// manual assertion with regex
jwtProperty.Remove();

var expectedOtherFields = JObject.Parse(@"{
  ""token_type"":""Bearer"",
  ""expires_in"":3600
}");
actual.Should().BeEquivalentTo(expectedOthers);

Another idea, but more complex to implement I believe, would be to allow specifying a regex comparer for certain fields.

Update

After looking at the source code, I tried with:

actual.Should().ContainSubtree(@"{
  ""token_type"":""Bearer"",
  ""expires_in"":3600
}");

This works but in case of error, it's impossible to understand what is wrong with the actual JSON as the message simply is:

Message: Expected JSON document to contain subtree {  "token_type": "Bearer",  "expires_in": 3600} , but some elements were missing.

[dennisdoomen]

Yeah, JSON support is pretty limited right now and we do not get a lot of feature request for this part of FA.

[david-ttl]

Is there any plan to implement something like this in the near future? I could really use it

[dennisdoomen]

No, not really. The JSON implementation was a contribution by somebody else. I myself am not using it very often. But we would welcome PRs.