To check doubles using precision when comparing JSON's, I am using the following options callback in BeEquivalentTo:
options => options.Using<double>(d => d.Subject.Should().BeApproximately(d.Expectation, 0.001))
.WhenTypeIs<double>()
But it seems that this builder callback is being called for every value comparison.
JTokenDifferentiator.CompareValues contains:
using (var scope = new AssertionScope())
{
actual.Value.Should().BeEquivalentTo(expected.Value, options =>
(JsonAssertionOptions<object>)config.Invoke(new JsonAssertionOptions<object>(options)));
hasMismatches = scope.Discard().Length > 0;
}
With the addition of the Using, a bigger json (MB's) goes from 200ms to +10s on my PC.
As a workaround, I replicated the behavior of the builder by accessing the userEquivalencySteps field on SelfReferenceEquivalencyAssertionOptions using reflection and inserting a custom IEquivalencyStep, instead of using the fluent API.
This brings it to 1s, which is acceptable for my use case.
Would it make sense to not call this options callback for every JSON value and build it once?
Or would adding API to add a custom IEquivalencyStep instead of the builder make sense?
To check doubles using precision when comparing JSON's, I am using the following options callback in
BeEquivalentTo:But it seems that this builder callback is being called for every value comparison.
JTokenDifferentiator.CompareValues contains:
With the addition of the Using, a bigger json (MB's) goes from 200ms to +10s on my PC.
As a workaround, I replicated the behavior of the builder by accessing the
userEquivalencyStepsfield onSelfReferenceEquivalencyAssertionOptionsusing reflection and inserting a customIEquivalencyStep, instead of using the fluent API.This brings it to 1s, which is acceptable for my use case.
Would it make sense to not call this options callback for every JSON value and build it once?
Or would adding API to add a custom
IEquivalencyStepinstead of the builder make sense?