Java JUnit：方法 X 对于类型 Y 不明确
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1811103/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java JUnit: The method X is ambiguous for type Y
提问by Nick Heiner
I had some tests working fine. Then, I moved it to a different package, and am now getting errors. Here is the code:
我有一些测试工作正常。然后，我将它移到另一个包中，现在出现错误。这是代码：
import static org.junit.Assert.*;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;
import org.jgrapht.Graphs;
import org.jgrapht.WeightedGraph;
import org.jgrapht.graph.DefaultWeightedEdge;
import org.jgrapht.graph.SimpleWeightedGraph;
import org.junit.*;
@Test
public void testEccentricity() {
WeightedGraph<String, DefaultWeightedEdge> g = generateSimpleCaseGraph();
Map<String, Double> eccen = JGraphtUtilities.eccentricities(g);
assertEquals(70, eccen.get("alpha"));
assertEquals(80, eccen.get("l"));
assertEquals(130, eccen.get("l-0"));
assertEquals(100, eccen.get("l-1"));
assertEquals(90, eccen.get("r"));
assertEquals(120, eccen.get("r-0"));
assertEquals(130, eccen.get("r-1"));
}
The error message is this:
错误信息是这样的：
The method assertEquals(Object, Object) is ambiguous for the type JGraphtUtilitiesTest
方法 assertEquals(Object, Object) 对于 JGraphtUtilitiesTest 类型是不明确的
How can I fix this? Why did this problem occur as I moved the class to a different package?
我怎样才能解决这个问题？为什么在我将类移动到不同的包时会出现这个问题？
采纳答案by Pascal Thivent
The method assertEquals(Object, Object) is ambiguous for the type ...
方法 assertEquals(Object, Object) 对于类型不明确...
What this error means is that you're passing a doubleand and Doubleinto a method that has two different signatures: assertEquals(Object, Object)and assertEquals(double, double)both of which could be called, thanks to autoboxing.
这个错误是什么意思是，你传递一个double与和Double成拥有两个不同的签名的方法：assertEquals(Object, Object)与assertEquals(double, double)这两方面都可以被调用，由于自动装箱。
To avoid the ambiguity, make sure that you either call assertEquals(Object, Object)(by passing two Doubles) or assertEquals(double, double)(by passing two doubles).
为避免歧义，请确保您要么调用assertEquals(Object, Object)（通过传递两个assertEquals(double, double)双精度数）要么（通过传递两个双精度数）。
So, in your case, you should use:
因此，在您的情况下，您应该使用：
assertEquals(Double.valueOf(70), eccen.get("alpha"));
Or:
或者：
assertEquals(70.0d, eccen.get("alpha").doubleValue());
回答by Paolo
You can use the method
您可以使用该方法
assertEquals(double expected, double actual, double delta)
Which will take into account rounding error that are hinerent to floating point (see this postfor example). You can write
这将考虑到浮点数固有的舍入误差（例如，参见这篇文章）。你可以写
assertEquals(70, eccen.get("alpha"), 0.0001);
This mean that as long as the two values differ for less than 0.0001 they are considered to be equals. This has two advantages:
这意味着只要两个值的差异小于 0.0001，它们就被认为是相等的。这有两个好处：
- Compares floating point values as they are supposed to
- No need to cast, as the three argument assert only applyes to doubles, not to generic Objects
- 按预期比较浮点值
- 无需强制转换，因为三个参数 assert 仅适用于双打，不适用于通用对象
回答by Fran Marzoa
The simplest solution to this problem is just cast the second parameter into a primitive:
这个问题最简单的解决方案是将第二个参数转换为一个原始参数：
assertEquals(70, (double)eccen.get("alpha"));
Ambiguity removed.
歧义消除。
This is valid for any of the Number subclasses, for example:
这对任何 Number 子类都有效，例如：
assertEquals(70, (int)new Integer(70));
Would solve an ambiguity too.
也能解决歧义。
However, assertEquals(double, double) is deprecated as of now and for good reasons, so I encourage you to use the method with a delta as others have suggested already.
但是，assertEquals(double, double) 现在已被弃用，并且有充分的理由，因此我鼓励您像其他人已经建议的那样使用带有 delta 的方法。
By good reasons I mean that, given the inner representation of double numbers, two apparently equal double numbers can differ in an irrelevant infinitesimal fraction and wouldn't pass a test, but that doesn't mean that there's anything wrong with your code.
我的意思是，考虑到双数的内部表示，两个明显相等的双数可以在不相关的无穷小分数上不同并且不会通过测试，但这并不意味着您的代码有任何问题。
