Question

我目前正在使用JUnit 4.4和Java 1.6.x.在最近的代码修复之后，我们开始在方法的JUnit测试中获得此AssertionFailedError：

UtilityTest.testParseDate（4t）：周一1月15日09:26:07太平洋标准时间2001年预计：“星期一1月15日09:26:07太平洋标准时间2001”但是：“星期一1月15日09:26:07太平洋标准时间2001"

junit.framework.AssertionFailedError：UtilityTest.testParseDate（4t）：Mon Jan 15 09:26:07 PST 2001期望：但是：在UtilityTest.testParseDate（未知来源）

如您所见，预期和实际看起来相同，经过多次代码检查后，我们发现代码中没有明显的错误。使用实际数据的测试运行也产生了正确的（预期的）结果。

有没有人在JUnit之前看过这种行为，如果是的话，你找到原因和/或修复了吗？

我在Java和JUnit的早期版本中看到了同样的事情：当它发生时总是有点随机，通常唯一的修复“有效”是从头开始重新键入代码块。很奇怪，但这是消除此错误的唯一方法。我试图在这次行为中找到更具“具体”的东西。

谢谢，

-Richard

Answer 1

你可以发布UtilityTest.testParseDate（）的代码吗？

您是在日期值上使用 assertEquals（）还是以其他方式比较它们？如果是这样，你能断言毫秒时间戳是否相等而不是日期本身？

Answer 2

测试代码是：

Calendar cal = Calendar.getInstance();
Date today = new Date();
cal.set(2001, 0, 15, 9, 26, 07);  // Jan 15 2001, 09:26:07
// format 4 = ddd mmm dd hh:mm:ss TTT yyyy (with gettime)
assertEquals("UtilityTest.testParseDate(4t): Mon Jan 15 09:26:07 PST 2001", cal.getTime(),  Utility.parseDate("Mon Jan 15 09:26:07 PST 2001", today, true));

这是parseDate的样子（只是方法签名，因为代码很长）：

public static Date parseDate(String date, Date today, boolean gettime) {

我认为你可能会拥有它 - 即使它没有显示毫秒，它们也会有所不同。

Answer 3

就是这样 - 毫秒关闭了。明智地应用cal.clear()解决了问题。

JUnit产生奇怪的AssertionFailedError

3 个答案: