0

我目前正在使用 JUnit 4.4 和 Java 1.6.x。在最近的代码修复之后,我们开始在我对方法的 JUnit 测试中得到这个 AssertionFailedError:

UtilityTest.testParseDate(4t):2001 年 1 月 15 日星期一 09:26:07 PST 预期:“2001 年 1 月 15 日星期一 09:26:07 PST”,但是:“2001 年 1 月 15 日星期一 09:26:07 PST”

junit.framework.AssertionFailedError: UtilityTest.testParseDate(4t): Mon Jan 15 09:26:07 PST 2001 预期:但是是:在 UtilityTest.testParseDate(未知来源)

可以看到,预期的和实际的看起来一模一样,经过多次代码检查,我们没有发现代码中有明显的错误。使用实际数据进行的测试也产生了正确的(预期的)结果。

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

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

谢谢,

-理查德

4

3 回答 3

2

您可以发布 UtilityTest.testParseDate() 的代码吗?

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

于 2009-01-28T03:30:53.830 回答
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) {

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

于 2009-01-28T03:51:56.877 回答
0

That was it - the milliseconds were off. A judicious application of cal.clear() fixed the problem.

于 2009-01-28T18:05:38.713 回答