Question

我在JUnit测试中遇到以下同样的奇怪情况。

所以我有这个测试方法：

@Test
public void getNavInfoTest() throws ParseException {

    TirAliquotaRamoI expectedObject = new TirAliquotaRamoI();

    DateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
    Date date;

    date = formatter.parse("2015-08-01");

    Date dataInizio = formatter.parse("2015-08-01");
    Date dataFine = formatter.parse("2100-12-31");

    expectedObject.setDataElaborazione(date);
    expectedObject.setTassoLordoAnnuoAppl(BigDecimal.ZERO);
    expectedObject.setTassoGiornalieroNetto(BigDecimal.ZERO);
    expectedObject.setAliquota(BigDecimal.ONE);
    expectedObject.setDataInizio(dataInizio);
    expectedObject.setDataFine(dataFine);

    TirAliquotaRamoI tirAliquotaRamoI = pucManager.getNavInfo(date);

    assertEquals(tirAliquotaRamoI.getAliquota(), expectedObject.getAliquota());

}

最后，我只是测试tirAliquotaRamoI.getAliquota()（从数据库查询中获取）是否具有为创建的expectedObject定义的相同字段的相同值：

assertEquals(tirAliquotaRamoI.getAliquota(), expectedObject.getAliquota());

因此，使用BigDecimal.ONE constand创建预期对象的字段，并使用调试器，我可以看到它的值为1。

tirAliquotaRamoI.getAliquota()获得的值为1.000000000

因此，从理论上讲，两者都代表相同的值1，但测试失败了，我得到了：

java.lang.AssertionError: expected:<1.000000000> but was:<1>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:834)
    at org.junit.Assert.assertEquals(Assert.java:118)
    at org.junit.Assert.assertEquals(Assert.java:144)
    at com.fideuram.dbmanager.PucManagerTest.getNavInfoTest(PucManagerTest.java:90)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

为什么两者都代表ame 1.0值？如何解决此问题以通过测试？

Answer 1

原因是BigDecimal equals的实施方式。 BigDecimal.ONE构造为new BigDecimal(BigInteger.ONE, 1, 0, 1)。 equals方法以下列方式实现（来自JDK源代码）：

public boolean equals(Object x) {
    if (!(x instanceof BigDecimal))
        return false;
    BigDecimal xDec = (BigDecimal) x;
    if (x == this)
        return true;
    if (scale != xDec.scale)
        return false;
    long s = this.intCompact;
    long xs = xDec.intCompact;
    if (s != INFLATED) {
        if (xs == INFLATED)
            xs = compactValFor(xDec.intVal);
        return xs == s;
    } else if (xs != INFLATED)
        return xs == compactValFor(this.intVal);

    return this.inflated().equals(xDec.inflated());
}

因此只有两个BigDecimals具有相同的比例才相等。 ONE的比例小于返回的BigDecimal，因此它们不相等。

我看到一些答案说您可以使用BigDecimal的 floatValue 。好吧，你不能。在处理更大的数字时会使用BigDecimal，所以在这种情况下它会起作用，但这是一个糟糕的模式。

但幸运的是我们可以使用compareTo方法！

assertTrue(tirAliquotaRamoI.getAliquota().compareTo(expectedObject.getAliquota()) == 0);

它不完美但会起作用！

Answer 2

在我看来，他们有不同的scales。

尝试compareTo：

 assertEquals(0, tirAliquotaRamoI.compareTo(expectedObject.getAliquota());

或者如果你关心匹配比例，那么你将不得不使用setScale（int newScale）更改任一对象的比例以匹配另一个。

希望有所帮助。

感谢@David SN进行更正。

Answer 3

BigDecimal比较也总是使用比例，因此您的测试失败。

有关详细信息，请参阅Javadoc。

如果您只对值而不是比例感兴趣，请在比较时考虑使用stripTrailingZeros（）。

assertEquals(
    tirAliquotaRamoI.getAliquota().stripTrailingZeros(),
    expectedObject.getAliquota().stripTrailingZeros()
);

Answer 4

虽然我不知道JUnit方法，但我猜这个问题与：

有关

public boolean equals（Object x）

将此BigDecimal与指定的Object进行相等性比较。   与compareTo不同，此方法认为两个BigDecimal对象相等   只有它们的价值和规模相等（因此2.0不等于   2.00用这种方法比较时。）

（见BigDecimal.equals() docs）

可能assertEquals()正在使用上述方法，该方法比较数字的值和比例。

您可能希望按assertTrue()

中的建议尝试使用x870eaddd's answer的方法

Answer 5

试试这个：

assertEquals((int)tirAliquotaRamoI.getAliquota(), (int)expectedObject.getAliquota());

我认为AssertEquals只能比较同一类型的两个变量（int到int，double到double ...）。在你的测试中，一个是小数，另一个不是，所以它可能无法比较它们。

Answer 6

tirAliquotaRamoI.getAliquota()的数据类型是什么？是BigDecimal也是因为BigDecimal.ONE是BigDecimal数据类型。

如果tirAliquotaRamoI.getAliquota（）为Long或Int或Float，则可以使用

assertEquals(tirAliquotaRamoI.getAliquota(), BigDecimal.ONE.intValue())

或

assertEquals(tirAliquotaRamoI.getAliquota(), BigDecimal.ONE.longValue())

如何比较BigDecimals以使我的测试通过？

6 个答案: