Assert function for testing floating point equality

[Irubataru]

Justification
I have a couple of unit tests where I have to check for floating point equality, and that can sometimes cause some problems. At the moment I have to make a separate function that returns a boolean and then use "IsTrue" instead.

Description
Would be great if we could have a separate AreEqualNumeric or something like that which checks for value equality taking things like floating point quirks into account. Possibly also allowing optional arguments for setting absolute/relative precision so that one can get information in the test explorer on values if the assert fails.

Optional suggestion
Another possibility would be to let the user themselves define assert'ers and have a special ExpectThat where you can pass an instance of an assert object defined in VBA with some expected methods such as Assert, Report etc which is what is used to fill out the test explorer with information. Then if I had implemented my own double precision assert class I could write

Assert.ExpectThat DoublesAreEqual, Number1, Number2, "Numbers from calculation are equal"

Where the DoublesAreEqual is some class in my VBA project with the necessary methods.

I have probably been informed before, but I am not entirely sure to what extent the Rubberduck can interact with the VBA code, so obviously I have no idea if this can be done. If it is possible then I can always spin this into a separate suggestion. If it could then that would also provide an additional workaround for the PermissiveAssert you have in your pipeline. This would also e.g. let users write special checkers for class equality etc so that you can reduce the number of asserts in a test.

[bclothier]

Just as a matter of note - there are few ways to handle the roundings (at least that I know of).

1. Absolute epsilon: Abs(a - b) < c.
2. Relative epsilon: Abs(a/b) < c
3. Units in the last place: Abs(ReinterpretAsLngLng(a) - ReinterpretAsLngLng(b)) < c

Of the 3, the last is difficult to implement in VBA as it does not allow reading the doubles as integers without using API. Each has their advantages and disadvantages, since it can depend on what kind of range one is dealing. For typical values (e.g. not much more than 4 digits to right and not dealing with numbers greater than hundred trillions normally), absolute epsilon is usually good enough. For large variance in range used, ULPS gives most stable behavior as it is not subject to the variances in the rounding errors as the values get bigger or smaller.

[Irubataru]

In general I am mostly in favour of ULPs as they seem the most correct in addressing the specific issue of floating point behaviour due to limited precision. On the other hand though using epsilons is useful for when you only expect your number to be correct to a certain precision. For example if you are implementing a numeric integration algorithm and want to test it with a known integral up to a certain precision.

In more general terms the reason I want an assert for these things is because it provides additional information in the test explorer; if it hadn't it wouldn't really matter whether IsTrue was the only assert there was. This is also why I noted the optional solution which is to let the user define the asserts themselves as you will never be able to satisfy every need.