Meaning of Delta or Epsilon Argument of Assertequals for Double Values

Meaning of delta or epsilon argument of assertEquals for double values

Epsilon is the value that the 2 numbers can be off by. So it will assert to true as long as Math.abs(expected - actual) <= epsilon

JUnit assertEquals(double expected, double actual, double epsilon)

Epsilon is your "fuzz factor," since doubles may not be exactly equal. Epsilon lets you describe how close they have to be.

If you were expecting 3.14159 but would take anywhere from 3.14059 to 3.14259 (that is, within 0.001), then you should write something like

double myPi = 22.0d / 7.0d; //Don't use this in real life!
assertEquals(3.14159, myPi, 0.001);

(By the way, 22/7 comes out to 3.1428+, and would fail the assertion. This is a good thing.)

How to Assert Two doubles in JUnit Using assertEquals with Epsilon?

You need to add a fourth parameter to the assertEquals call: the threshold within which two doubles should be considered "equal". Your call should look like this:

assertEquals("Wrong max possible value for %" + percentage, 110.42,
        processor.calcPossibleValue(percentage), 0.01);

The above call would indicate that if the value returned by processor.calcPossibleValue(percentage) is within ± 0.01 of 110.42, then the two values are considered equal. You can change this value to make it as small as is necessary for your application.

See the JUnit documentation for more information.

How to call assertEquals with Double Epsilon/Precision in Kotlin?

I have figured it out!

This is how it's done

import org.junit.*
import Kotlin.Test.assertEquals

Assert.assertEquals(expected, actual, precision) // to use the jUnit standard one
assertEquals(expected, actual, message) // to use the Kotlin one

TestNG AssertEquals double - good number to put for a double?

If you want your test to fail for 121.97 and 121.96...
try using delta that is smaller than

|121.97 - 121.96| = 0.01.

How about:

final double DELTA = 0.001;
assertEquals(121.97, 121.96, DELTA);

Output:

java.lang.AssertionError: expected [121.96] but found [121.97]
Expected :121.96
Actual   :121.97

In general case... if you want your assertion to fail for a and b,

use delta that is smaller than |a - b|.

Junit difference between assertEquals(Double, Double) and assertEquals(double, double, delta)

There is NO assert method in JUnit with the signature

assertEquals(Double expected, Double result);

There is one, however, generic for objects:

assertEquals(Object expected, Object result);

This calls the objects' equals method and as you can expect, it is not recommended to use this for comparing Double objects.

For doubles, as you observed, it is absolutely necessary to use a delta for comparison, to avoid issues with floating-point rounding (explained already in some other answers). If you use the 3-argument version of assertEquals with double arguments

assertEquals(double expected, double actual, double delta);

your Doubles will get silently unboxed to double and everything will work fine (and your tests won't fail unexpectedly :-).

Why is assertEquals(double,double) deprecated in JUnit?

It's deprecated because of the double's precision problems.

If you note, there's another method assertEquals(double expected, double actual, double delta) which allows a delta precision loss.

JavaDoc:

Asserts that two doubles are equal to within a positive delta. If they are not, an AssertionError is thrown. If the expected value is infinity then the delta value is ignored.NaNs are considered equal: assertEquals(Double.NaN, Double.NaN, *) passes

...

delta - the maximum delta between expected and actual for which both numbers are still considered equal.

assertEquals Precision

You are using:

assertEquals(double expected, double actual, double epsilon)

Since doubles may not be exactly equal in any language (precision issues), epsilon allows you to describe how close they have to be.

Epsilon is defined as the maximal deviation from the expected result:

Math.abs(expected - actual) < epsilon

So in essence it allows you to deviate from the expected outcome (3.0 or 3.3 in your cases) by

Arithmetic.divide(12.0, 4.0) - 3.0 = 3.0 - 3.0 = 0 and

Arithmetic.divide(10.0, 3.0) - 3.3 ≈ 3.3333333 -3.3 ≈ 0.3333333 respectively.

So in the first one as you see, there is actually no need for an epsilon since the expected and actual results are exactly the same.
In the second one you should allow some deviation as you see that the actual result is approximately > by 0.33333 than the expected one.

---

Related Topics