Handling Floating-Point Precision in Java’s assertEquals

Comparing floating-point numbers in Java can be challenging due to precision limitations in how these values are represented. When writing unit tests with JUnit, using assertEquals for float or double values requires special care to account for these small discrepancies. This article explains how to manage floating-point comparisons effectively with JUnit’s assertEquals method.

Understanding Floating-Point Precision

Floating-point numbers in Java follow the IEEE 754 standard. Because many decimal fractions cannot be represented exactly in binary (for example, 0.1), calculations can introduce tiny rounding errors. As a result, direct comparisons between two floating-point values often fail even when the numbers appear equal. For a clear primer, see the Floating-Point Guide (floating-point-gui.de) and the classic paper “What Every Computer Scientist Should Know About Floating-Point Arithmetic” (Oracle).

The Role of assertEquals in JUnit

In unit tests, assertEquals is commonly used to compare expected and actual values. With floating-point types, using the two-argument overload (assertEquals(expected, actual)) is risky because it demands exact equality and will frequently fail due to precision noise. JUnit therefore provides an overload that accepts a third argument, often called delta or tolerance, which specifies the maximum acceptable difference between the expected and actual values for the assertion to pass.

• JUnit 5: see the user guide on assertions (junit.org).
• JUnit 4: see the Javadoc for Assert.assertEquals(double, double, double) (junit.org).

Implementing assertEquals with a Delta

Use the three-parameter overload to compare floating-point values:

// JUnit 5 example
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;

class FloatingPointTestJupiter {
    @Test
    void testFloatingPointComparison() {
        double expected = 0.3;
        double actual = 0.1 + 0.2;
        double delta = 1e-10; // acceptable tolerance
        assertEquals(expected, actual, delta);
    }
}

// JUnit 4 example
import static org.junit.Assert.assertEquals;
import org.junit.Test;

public class FloatingPointTest {
    @Test
    public void testFloatingPointComparison() {
        double expected = 0.3;
        double actual = 0.1 + 0.2;
        double delta = 1e-10; // acceptable tolerance
        assertEquals(expected, actual, delta);
    }
}

Choosing a good delta matters. It should be small enough to catch real errors but large enough to absorb harmless rounding differences. For double, deltas like 1e-12 to 1e-9 are common; for float, use a larger tolerance (e.g., 1e-5 to 1e-6). For more background on comparison strategies, see the Floating-Point Guide’s notes on comparisons (floating-point-gui.de).

Best Practices for Floating-Point Comparisons

• Choose an appropriate delta: Base the tolerance on your domain. For high-precision numerical work, use a smaller delta. For business logic or less sensitive calculations, a slightly larger delta is fine. When values may vary in magnitude, consider deriving an absolute delta from a relative tolerance, for example:

  double rel = 1e-9;
  double abs = 1e-12;
  double delta = Math.max(abs, rel * Math.max(Math.abs(expected), Math.abs(actual)));
  

• Use BigDecimal for exact decimal arithmetic: If you need precise decimal math (e.g., money), use BigDecimal and construct values from strings (e.g., new BigDecimal("0.1")) to avoid binary rounding issues. See the BigDecimal API (Oracle).
• Avoid direct equality checks: Don’t compare floating-point numbers with == or use the two-argument assertEquals. Always provide a delta when asserting on double or float.
• Be explicit about rounding: When converting or formatting results, specify the rounding mode to keep behavior deterministic.

Conclusion

Floating-point precision requires careful handling, especially in unit tests. By using JUnit’s assertEquals with a suitable delta, you can account for minor rounding errors and keep your tests meaningful. For domains that demand exact decimal behavior, prefer BigDecimal. Applying these practices leads to more robust and trustworthy tests.

For a concise walkthrough of assertion techniques in JUnit, this video may help: