Java / JUnit - AssertTrue vs AssertFalse
Je suis assez nouveau sur Java et je suis les tutoriels du débutant Eclipse Total . Ils sont tous très utiles, mais dans la Leçon 12, il utilise assertTrue pour un cas de test et assertFalse pour un autre. Voici le code:
// Check the book out to p1 (Thomas)
// Check to see that the book was successfully checked out to p1 (Thomas)
assertTrue("Book did not check out correctly", ml.checkOut(b1, p1)); // If checkOut fails, display message
assertEquals("Thomas", b1.getPerson().getName());
assertFalse("Book was already checked out", ml.checkOut(b1,p2)); // If checkOut fails, display message
assertEquals("Book was already checked out", m1.checkOut(b1,p2));
J'ai cherché une bonne documentation sur ces méthodes, mais je n'ai rien trouvé. Si ma compréhension est correcte, assertTrue ainsi que assertFalse affichage de la chaîne lorsque le deuxième paramètre est false. Si oui, quel est l'intérêt d'avoir les deux eux?
Edit: je pense que je vois ce qui me déroutait. L'auteur peut avoir mis les deux juste pour montrer leur fonctionnalité (c'est un tutoriel après tout). Et il a mis en place un qui échouerait, de sorte que le message serait imprimé et me dire pourquoi il a échoué. Commencer à faire plus de sens...Je pense que c'est l'explication, mais je ne suis pas sûr.
7 réponses
assertTrue échouera si le deuxième paramètre est évalué à false (en d'autres termes, il garantit que la valeur est true). assertFalse fait le contraire.
assertTrue("This will succeed.", true);
assertTrue("This will fail!", false);
assertFalse("This will succeed.", false);
assertFalse("This will fail!", true);
Comme beaucoup d'autres choses, la meilleure façon de se familiariser avec ces méthodes est juste de l'expérience :-).
Votre compréhension est incorrecte, Dans de tels cas, consultez toujours le JavaDoc .
AssertFalse
public static void assertFalse(java.lang.String message, boolean condition)Affirme qu'une condition est fausse. Si ce n'est pas le cas, il lance une AssertionError avec le message donné.
Paramètres:
message- le message d'identification pour L'AssertionError (null okay)condition- condition à vérifier
Le point est la sémantique. Dans assertTrue, vous affirmez que l'expression est vraie. Si ce n'est pas le cas, il affichera le message et l'assertion échouera. Dans assertFalse, vous affirmez qu'une expression est évaluée à false. Si ce n'est pas le cas, le message s'affiche et l'assertion échoue.
assertTrue (message, value == false) == assertFalse (message, value);
Ceux-ci sont fonctionnellement les mêmes, mais si vous attendez qu'une valeur soit false, utilisez assertFalse. Si vous attendez qu'une valeur soit true , utilisez assertTrue.
Je pense que c'est juste pour votre commodité (et les lecteurs de votre code)
Votre code, et vos tests unitaires devraient idéalement être auto-documentés avec lesquels cette API aide,
Pensez à ce qui est plus clair à lire:
AssertTrue(!(a > 3));
Ou
AssertFalse(a > 3);
Lorsque vous ouvrez vos tests après xx mois lorsque vos tests échouent soudainement, il vous faudrait beaucoup moins de temps pour comprendre ce qui a mal tourné dans le second cas (mon avis). Si vous n'êtes pas d'accord, vous pouvez toujours rester avec AssertTrue pour tous cas :)
Votre première réaction à ces méthodes est assez intéressante pour moi. Je l'utiliserai dans de futurs arguments selon lesquels assertTrue et assertFalse ne sont pas les outils les plus conviviaux. Si vous voulez utiliser
assertThat(thisOrThat, is(false));
, Il est beaucoup plus lisible, et il imprime un meilleur message d'erreur trop.
assertTrue échoue si la valeur est false, et assertFalse va faire l'inverse: d'échouer si la valeur est true.
Une autre chose, vos derniers assertEquals échoueront très probablement, car ils compareront la chaîne" Book was already checked out " avec la sortie de m1.caisse (b1, p2). Il a besoin d'un troisième paramètre (la deuxième valeur pour vérifier l'égalité).
Le cours contient une erreur logique:
assertTrue("Book check in failed", ml.checkIn(b1));
assertFalse("Book was aleready checked in", ml.checkIn(b1));
Dans la première affirmation, nous nous attendons à ce que le checkIn retourne True (car checkin est réussi). Si cela échouait, nous imprimerions un message comme " book check in failed. Maintenant, dans la deuxième affirmation, nous nous attendons à ce que le checkIn échoue, car le livre a déjà été enregistré dans la première ligne. Nous nous attendons donc à ce qu'un checkIn renvoie un faux. Si pour une raison quelconque checkin renvoie un vrai (ce que nous n'attendons pas) que le message ne devrait jamais être " Book était déjà enregistré", parce que le checkin a été couronné de succès.