Extend use of tolerance to ComparisonConstraints

[NUnitTester]

The WithIn Option is available for Is.EqualTo. That's fine, but it is missing for the other ones:
double x = ...; Assert.That(x, Is.GreaterThan(1.0).WithIn(1.0e-12));

The interpretation is:
if (x <= 1.0 - 1.0e-12) Assert.Fail(...);
It is expected to have this for:
GreaterThan
GreaterThanOrEqualTo
LessThan
LessThanOrEqualTo
AtLeast
AtMost

[jnm2]

It's capitalized WithIn? That's a bug in and of itself...

[CharliePoole]

@NUnitTester I'd like to first clarify that this isn't a bug but how the feature is designed to work...

The Within modifier is available on EqualConstraint in order to specify a tolerance (plus or minus) for defining equality. It may be used without regard to the Type of the actual or expected value, so it has nothing particular to do with float or double. If specified, it is used whenever the type being compared is numeric, a TimeSpan or a DateTime. It takes further modifiers that allow you to tell the constraint to use the value given as a percent, a number of minutes, etc. When used on collections, the tolerance only comes into play when the members of the collection are of a type where it makes sense. For example, if you compare two object arrays that hold both ints and strings in different positions, the tolerance is only used for the ints.

I outline all this so you can understand that the features of WithIn are very much bound up with the features of EqualConstraint. It was designed for equality comparisons and was never intended to work with other constraints. The idea was certainly considered when we designed it, but we didn't see a strong need and would have had to implement it a bit differently in any case.

With a comparison constraint, you always have the choice of specifying the exact value to be used, just as you did in your example.

Assert.That(x, Is.GreaterThan(1.0 - 1.0e-12);

I will grant that the use of Within would provide a bit better documentation of what you are testing and might avoid errors in choosing whether to add or subtract the tolerance amount, depending on the type of comparison.

My judgement is that this would be a relatively low priority new feature and probably one we would invite an interested contributor to take on. As a start, my suggestion is that you state more precisely what you would like to work with comparison constraints:

• Simple Within plus a number?
• DateTime?
• Other modifiers that are permitted after Within on EqualConstraint? (see docs)
  Once we know what we are aiming for, we can decide whether to add this to our backlog.

[NUnitTester]

Sorry for the late answer. I not thought about a bug, it is a feature request. I like Within, but I cannot use it if I need GreaterOrEqual and it is a great feature to make clear, that mathematically correct is 1.0, but numerically it is only nearby and expected to have a maximum error of 1.0e-12.

• Simple within plus number? - I don't know what else is possible. Might be I don't understand.
• DateTime: Yes, that will be great to for performance issues. 1 second within 20 milliseconds.
• Modifiers like percent and ulps? Yes, should be like in EqualConstraint.

[CharliePoole]

So it appears that @NUnitTester is suggesting pretty much the same accepted syntax for comparison constraints that we use for EqualsConstraint. That probably means refactoring into a common base.

@nunit/framework-team @nunit/core-team I'm in favor of this. What do you guy think?

[rprouse]

I am in favor if it doesn't introduce too much complexity into the existing constraints 👍

[NUnitTester]

Fine. I'm happy for that!

[CharliePoole]

@nunit/framework-team Here is a simplifying idea for implementation. Does it make sense?

Rather than the obvious implementation for comparison within a tolerance, I could use the existing code for equality within a tolerance. That is, when a tolerance is provided and expected and actual are equal within that tolerance, all four comparisons would pass. Otherwise, we would use the normal comparison without tolerance. My only concern would be boundary issues, which we have already with equality, since there is no way to specify whether a range is inclusive or exclusive. Thoughts?