REST混乱确保浮点比较 [英] Confusion over REST Assured floating-point comparisons

问题描述

REST保证的使用文档具有如下示例:

The REST Assured usage documentation has examples like this:

get("/lotto").then().body("lotto.lottoId", equalTo(5));

好的，因此他们正在使用Hamcrest匹配器与int值5进行比较.

OK, so they are using a Hamcrest matcher to compare to the int value 5.

但是他们有一节说，默认情况下，REST Assured JSON解析器使用的是float而不是double，因此，我不应该将其与12.12进行比较，而应将其与12.12f进行比较:

But they have a section saying that the REST Assured JSON parser by default uses float and not double, so instead of comparing to 12.12 I should compare to 12.12f:

get("/price").then().body("price", is(12.12f));

等等，那么5是上面的int而不是double是如何工作的? JSON解析器是否对整数和非整数值使用不同的原语?

Wait, so how did 5 work above, which is an int and not a double? Does the JSON parser use different primitives for integer and non-integer values?

但是它变得更加令人困惑.精通编程的人都知道，无论如何您都不应该直接比较浮点值(因为浮点值的存储方式很复杂，等等).相反，您应该使用 Matchers.closeTo(double operand, double error) 可以提供一定的误差.这是正确的方法.但是，等等-即使我将12.12f传递给Matchers.closeTo(double operator，double error)，它是否仍将其转换为double?可以与REST Assured一起使用吗?

But it gets more confusing. Well-versed programmers know that you shouldn't be comparing floating point values directly anyway (because of the intricacies of how floating-point values are stored, etc.). Instead you should use Matchers.closeTo(double operand, double error) which provides a margin of error. This is the correct way to do it. But wait --- even if I pass in 12.12f to Matchers.closeTo(double operand, double error), isn't it still going to convert it to a double? Will this work with REST Assured?

推荐答案

我不是100％肯定我在这里是正确的，但是这篇文章过长，无法发表评论...

I'm not 100% sure I'm correct here, but this post became too long for a comment...

通过阅读 Hamcrest的文档和 REST保证似乎equalTo仅在Object.equals返回true的情况下返回true:

From reading the docs for Hamcrest and REST Assured it seems like equalTo only returns true in the cases that Object.equals returns true:

[equalTo]创建一个匹配器，该匹配器在被检查对象在逻辑上等于指定的操作数时进行匹配，这是通过在被检查对象上调用Object.equals(java.lang.Object)方法来确定的.

[equalTo] Creates a matcher that matches when the examined object is logically equal to the specified operand, as determined by calling the Object.equals(java.lang.Object) method on the examined object.

因此，由于REST Assured将浮点值表示为浮点，并且Double.equals仅可以在其他对象是Double的情况下返回true，因此必须使用float而不是double(因为输入将装箱成一个对象).

Thus since REST Assured represents floating point values as floats, and Double.equals can only return true if that other object is a Double, it is necessary to use a float and not a double (as the input will get boxed into an object).

此外，REST保证文档中的浮点部分似乎表明它仅适用于浮点值:

Also, the section of floats in the REST Assured docs seems to indicate it only applies to floating point values:

浮点数必须与Java"float"原语进行比较.

Floating point numbers must be compared with a Java "float" primitive.

我认为这意味着整数可以正确地表示为Integers. (文档中的其他示例似乎也表明了这一点)

I presume that means that integers are represented properly as Integers. (Other examples in the docs also seems to suggest this)

如果您选择使用Matchers.closeTo代替equalTo或is(其本身称为equalTo)，那么使用double还是float都没有关系.

If you chose to use Matchers.closeTo instead of equalTo or is (which itself calls equalTo), then it shouldn't matter if you use a double or a float.

这篇关于REST混乱确保浮点比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！