2009-01-28 88 views
0

我目前正在使用JUnit 4.4和Java 1.6.x.而最近代码修复后,我们开始得到这个AssertionFailedError异常在我的JUnit测试的方法:JUnit产生奇怪的AssertionFailedError

UtilityTest.testParseDate(4T):星期一1月15日9时26分07秒的PST 2001年预计:“周一1月15日09: 26:07 PST 2001" ,但是却是: “周一1月15日2001年”

junit.framework.AssertionFailedError 9时26分07秒的PST:UtilityTest.testParseDate(4T):星期一1月15日9时26分07秒的PST 2001预期:但是: at UtilityTest.testParseDate(未知来源)

正如您所看到的,预期和实际显示的内容完全相同, l代码检查,我们可以发现代码中没有明显的错误。用实际数据测试运行也会产生正确的(预期的)结果。

有没有人在JUnit中看到过这种行为,如果是这样,你找到了原因和/或修复?

我在以前的Java和JUnit自己版本中看到过同样的情况:发生时总是有点随意,通常唯一修复“工作”的是从头开始重新输入代码块。奇怪,但这是消除此错误的唯一方法。我试图在这次行为中找出更“具体”的东西。

感谢,

- 理查德

回答

2

你能张贴UtilityTest.testParseDate代码()?

对日期值使用assertEquals()还是以另一种方式比较它们?如果是这样,你能断言毫秒时间戳是相等的,而不是日期本身?

+0

感谢捅我的大脑思考毫秒! – Huntrods 2009-01-28 18:06:17

1

测试代码是:

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) { 

我认为你可能有它虽然 - 即使它不会显示毫秒,它们会有所不同。

+0

这可能会解释测试用例传递和失败的明显“随机性”。有时这些指令会在不到一毫秒的时间内完成,在这种情况下,您的测试将会起作用。 – Kevin 2009-01-28 03:55:23

0

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