2009-01-28 4 views
0

J'utilise actuellement JUnit 4.4 et Java 1.6.x. Et après une correction de code récente, nous avons commencé à obtenir cette AssertionFailedError dans mes tests JUnit sur la méthode:JUnit produit étrange AssertionFailedError

UtilityTest.testParseDate (4t): Mon Jan 15 09:26:07 PST 2001 attendue: "Lun Jan 15 09: 26:07 PST 2001" , mais était: "Mon 15 janvier 09:26:07 PST 2001"

junit.framework.AssertionFailedError: UtilityTest.testParseDate (4t): lun 15 janvier 09:26:07 PST 2001 attendu: mais était: à UtilityTest.testParseDate (source inconnue)

Comme vous pouvez le voir, le attendu et réel semblent identiques, et après severa l inspections de code, nous ne pouvons trouver aucune erreur évidente dans le code. Des tests avec des données réelles ont également produit des résultats corrects (attendus).

Quelqu'un a déjà vu ce comportement dans JUnit, et si oui, avez-vous trouvé la cause et/ou une solution? J'ai vu la même chose dans les versions précédentes de Java et de JUnit: toujours un peu aléatoire quand il se produit, et le seul correctif qui a fonctionné était de retaper le morceau de code de zéro. Bizarre, pourtant c'était le seul moyen de supprimer cette erreur. J'essaie de trouver quelque chose de plus "concret" dans le comportement cette fois-ci.

Merci,

-Richard

Répondre

2

Pouvez-vous envoyer le code pour UtilityTest.testParseDate()?

Utilisez-vous assertEquals() sur les valeurs de date ou les comparez-vous d'une autre manière? Si oui, pouvez-vous affirmer que les horodatages millisecondes sont égaux au lieu des dates elles-mêmes?

+0

Merci d'avoir poussé mon cerveau à penser aux millisecondes! – Huntrods

1

Le code de test est:

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

Voici ce que parseDate ressemble (juste la signature de la méthode que le code a été long):

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

Je pense que vous pouvez l'avoir si - même si il n'affiche pas les millisecondes, ils seraient différents.

+0

Cela expliquerait probablement l'apparente "caractère aléatoire" du cas de test passant et échouant. Parfois, les instructions vont arriver en moins d'une milliseconde, auquel cas votre test fonctionnera. – Kevin

0

C'était tout - les millisecondes étaient coupées. Une application judicieuse de cal.clear() a résolu le problème.