【问题标题】:assertEquals doesn't work without second parameter casting没有第二个参数转换,assertEquals 不起作用
【发布时间】:2011-05-02 10:40:21
【问题描述】:

伙计们,为什么我在此 JUnit 测试中收到“方法 assertEquals(String, Object, Object) 对于 DictionaryTest 类型不明确”错误?

@Test
 public void testEditCard() {
  Integer a = 10;
  Integer b = 12;
  Integer c = 2;
  assertEquals("test", a-b, c);
 }

添加转换assertEquals("test", (Integer)(a-b), c); 可以解决问题。

【问题讨论】:

  • 注意:同样的问题和解决方案也适用于TestNG。

标签: java junit


【解决方案1】:

因为自动装箱和拆箱的奇妙之处:

assertEquals("test", /* this is an int */ a-b, /* this is an Integer */ c);

可以评价为

assertEquals(String, long, long);
// in this case the second parameter is unboxed
// (and the first one silently casted)

或作为

assertEquals(String, Object, Object);
// in this case the first parameter is boxed

如果将所有变量都声明为 int(不是 Integer),则应该没有歧义。

【讨论】:

  • 我有同样的问题,我需要整数(不是整数)。我应该使用哪个 assertequals??
【解决方案2】:

这是因为编译器无法判断您是要调用assertEquals(String, Object, Object) 还是assertEquals(String, long, long)。由于a-b 和c 可以自动强制转换为long,因此编译器会发现歧义。

您的显式转换告诉编译器您需要 Object 版本。

请注意,在这种情况下,您可以使用 int 而不是 Integer 变量,这也可以解决歧义。

【讨论】:

  • 查看 JUnit API 似乎没有 assertEquals(String, int, int) 这似乎很奇怪......我错过了什么吗? JUnit 人员真的决定强制使用longs 执行所有int 检查吗?还是我完全误读了junit.org/apidocs/org/junit/Assert.html 上的 API?
  • ints 可以代替 longs,但反过来不行。
  • 是的,我知道,这似乎是一个奇怪的设计决定。整数算术通常比长算术更快,尽管我想随着 32 位系统变得不那么普遍,这将变得不那么重要。我想单元测试的效率并不是什么大问题。
  • assertEquals 真的很奇怪,那么对于 Integer 的情况,最佳实践是什么?
猜你喜欢
  • 1970-01-01
  • 2023-02-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-05-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多