Le message JUnit doit-il indiquer la condition de succès ou d'échec ?

Question

Je peux écrire un message d'assertion de deux façons. En déclarant le succès :

assertEquals( "objects should be identical", expected, actual );

Ou en énonçant la condition d'être brisé :

assertEquals( "objects aren't identical", expected, actual );

Existe-t-il un standard pour cela dans JUnit spécifiquement ? Si non, quels sont les arguments de chaque partie ?

P.S. J'ai vu des articles sur le web qui démontrent ces deux choses sans explication, donc dire simplement "cherchez sur Google" n'est pas une réponse !

[MISE À JOUR]

Tout le monde s'accroche au fait que j'ai utilisé assertEquals et donc le message est probablement inutile. Mais bien sûr, c'est juste parce que je voulais illustrer la question simplement.

Alors imaginez plutôt que c'est :

assertTrue( ... big long multi-line expression ... );

Où un message est utile.

Answer 1

Je prends rarement la peine d'envoyer un message, au moins pour assertEquals . N'importe quel exécuteur de test sensé vous expliquera que vous utilisiez assertEquals et les deux choses qui devaient être égales. Aucun de vos messages ne donne plus d'informations que cela.

J'ai l'habitude de constater que les échecs des tests unitaires sont transitoires - je trouve rapidement ce qui ne va pas et je le répare. La "découverte de ce qui ne va pas" implique généralement suffisamment de détails pour qu'un seul message ne fasse pas une grande différence. Considérez le "temps économisé par la présence d'un message" par rapport au "temps passé à penser à des messages" :)

Ok, un cas où je pourrait utiliser un message : lorsqu'il existe une description compacte en texte qui n'est pas évidente à partir de la représentation en chaîne de l'objet.

Par exemple : "La date attendue est le 1er décembre" lors de la comparaison de dates stockées en millisecondes.

Je ne m'inquiéterais pas de la façon dont vous l'exprimez exactement : assurez-vous simplement que le message indique clairement ce que vous voulez dire. Que ce soit "devrait être" ou "n'était pas", ça va - "1er décembre" ne serait pas évident.

Answer 2

Selon l'API de Junit, le message est "le message d'identification de l'AssertionError". Il ne s'agit donc pas d'un message décrivant la condition qui doit être remplie, mais d'un message décrivant ce qui ne va pas si la condition n'est pas remplie. Ainsi, dans votre exemple, "les objets ne sont pas identiques" semble être plus conforme.

Answer 3

Contrairement à beaucoup d'autres, je pense que l'utilisation d'un message est extrêmement utile pour de nombreuses raisons :

1. La personne qui consulte les journaux d'un test raté n'est pas forcément celle qui a rédigé le test. Cela peut prendre du temps de lire le code et de comprendre quel cas l'assertion est censée traiter. Un message utile permet de gagner du temps.

2. Même dans le cas où c'est le développeur du test qui consulte les journaux, il se peut que des jours ou des mois se soient écoulés depuis que le test a été écrit et, là encore, un message peut faire gagner du temps.

Mon conseil serait de rédiger le message en indiquant le comportement attendu. Par exemple :

assertEquals("The method should be invoked 3 times", 3, invocationCount);

Answer 4

Je pense que cela n'a aucune importance - Vous savez déjà qu'un échec s'est produit, et donc il importe peu que le message indique ce qui aurait dû se produire, ou ce qui ne devait pas se produire.

Le but du message est de vous aider quand il le peut, et non d'obtenir une certaine exhaustivité.

Évidemment, dans le cas de assertEquals, cela est moins important, mais le message est important dans le cas des assertions générales. Le message devrait vous aider à obtenir suffisamment de contexte pour comprendre immédiatement ce qui a échoué.

Cependant, la quantité de contexte nécessaire (et donc les détails dans le message) devrait dépendre de la façon dont vous obtenez le rapport. Par exemple, si vous le recevez dans Eclipse, vous pouvez facilement interagir et voir ce qui s'est passé, le message est donc moins important. Cependant, si vous recevez vos rapports par e-mail (par exemple, à partir d'un serveur de construction continue), vous voulez que le message fournisse suffisamment d'informations pour que vous ayez une idée de ce qui se passe avant même d'accéder au code source correspondant.

Answer 5

Je voudrais répondre à la question sans réfléchir, si un message en générique est utile.

Si un test échoue, quelque chose ne va pas. Je le sais. Je veux savoir pourquoi c'est cassé. C'est très facile à découvrir car il me suffit d'ouvrir le cas de test et le SUT. Comme Jon l'a dit, il est très facile de le réparer (espérons-le ;-) ).

Mais qu'en est-il du message ? Le message est pour moi un conseil, ce qui pourrait être fait pour le transformer en un cas de test vert. J'apprécierais donc qu'un conseil soit donné dans le texte du message, sur la manière de résoudre ce problème ou sur l'endroit où chercher le problème.

Un autre aspect intéressant serait l'utilisation d'expressions positives. Cela vaut la peine d'envisager d'utiliser des SMS positifs. Dans votre exemple, j'utiliserais Objects should be identical . Mais c'est une petite raison.