Question Tests unitaires: Est-ce une bonne pratique d'avoir des assertions dans les méthodes de configuration?


Dans les tests unitaires, la méthode d'installation est utilisée pour créer les objets nécessaires au test.

Dans ces méthodes de configuration, j'aime bien utiliser des assertions: je sais quelles valeurs je veux voir dans ces objets, et j'aime documenter cette connaissance via une assertion.

Dans un post récent sur tests unitaires appelant d'autres tests unitaires ici sur stackoverflow, le sentiment général semble être que les tests unitaires devraient ne pas appeler d'autres tests: La réponse à cette question semble être que vous devriez refactoriser votre configuration, donc que les cas de test ne dépendent pas les uns des autres.

Mais il n'y a pas beaucoup de différence dans un "setup-with-asserts" et un test unitaire appelant d'autres tests unitaires.

D'où ma question: est-ce une bonne pratique d'avoir des assertions dans les méthodes de configuration?

MODIFIER:

La réponse est la suivante: ce n'est pas une bonne pratique en général. Si les résultats de l'installation doivent être testés, il est recommandé d'ajouter une méthode de test distincte avec les assertions (la réponse que j'ai cochée); pour documenter l'intention, envisagez d'utiliser des assertions Java.


28
2017-09-03 07:38


origine


Réponses:


Au lieu d'assertions dans la configuration pour vérifier le résultat, J'ai utilisé un test simple (une méthode de test avec les autres, mais positionnée comme première méthode de test).

J'ai vu plusieurs avantages:

  • le la configuration reste courte et ciblée, pour plus de lisibilité.
  • Les assertions sont exécutées une seule fois, ce qui est plus efficace.

Utilisation et discussion  :

Par exemple, je nomme la méthode testSetup ().

Pour l'utiliser, quand j'ai des erreurs de test dans cette classe, je sais que si testSetup () a une erreur, je n'ai pas besoin de me préoccuper des autres erreurs, je dois d'abord corriger celle-ci.

Si quelqu'un est dérangé par cela et veut rendre cette dépendance explicite, le testSetup () pourrait être appelé dans la méthode setup (). Mais je ne pense pas que cela compte. Mon point est que, dans JUnit, vous pouvez déjà avoir quelque chose de similaire dans le reste de vos tests:

  1. des tests qui testent le code local,
  2. et quelques tests qui appellent plus de code global, ce qui appelle indirectement le même code que le test précédent.

Lorsque vous lisez le résultat du test lorsque les deux échouent, vous devez déjà vous occuper de cette dépendance qui n'est pas dans le test, mais dans le code appelé. Vous devez d'abord corriger le test simple, puis réexécuter le test global pour voir s'il échoue toujours. C'est la raison pour laquelle je ne suis pas dérangé par la dépendance implicite que j'ai expliquée précédemment.


14
2017-09-03 08:56



Ils sont différents scénarios; Je ne vois pas la similitude.

Les méthodes d'installation doivent contenir du code commun à (idéalement) tout tests dans un appareil. En tant que tel, il n'y a rien de mal à insérer des assertions dans une méthode de configuration de test si certaines choses doivent être vraies avant que le reste du code de test ne s'exécute. La configuration est une extension du test; cela fait partie du test dans son ensemble. Si l'assertion se déclenche, les gens découvriront quels pré-requis ont échoué.

D'un autre côté, si la configuration est suffisamment complexe pour que vous sentiez le besoin d'affirmer qu'elle est correcte, cela peut être un signe d'avertissement. De plus, si tous les tests ne nécessitent pas la sortie complète de l'installation, cela signifie que l'unité manque de cohésion et devrait être divisée en fonction de scénarios et / ou refactorisés.

C'est en partie à cause de cela que j'ai tendance à ne pas utiliser les méthodes d'installation. Dans la mesure du possible, j'utilise des méthodes d'usine privées ou similaires pour configurer les choses. Cela rend le test plus lisible et évite toute confusion. Parfois, cela n'est pas pratique (par exemple, travailler avec des cours étroitement couplés et / ou lors de la rédaction de tests d'intégration), mais pour la majorité de mes tests, il fait le travail.


9
2017-09-03 07:47



Avoir des assertions dans les méthodes Setup / TearDown est déconseillé. Cela rend le test moins lisible si l'utilisateur doit "comprendre" qu'une partie de la logique de test ne se trouve pas dans la méthode de test. Il y a des moments où vous n'avez pas d'autre choix que d'utiliser les méthodes d'installation / de démontage pour autre chose que ce à quoi elles étaient destinées.

Il y a un plus gros problème dans cette question: un test qui appelle un autre test, c'est une odeur de problème dans vos tests. Chaque test doit tester un aspect spécifique de votre code et ne doit contenir qu’une ou deux assertions. Par conséquent, si votre test appelle un autre test, il se peut que vous testiez trop de choses dans ce test. Pour plus d'informations, lisez: Test unitaire: un test, une affirmation - pourquoi cela fonctionne


9
2017-09-03 07:53



Suivez vos décisions coeur / clignement. Les assertions dans une méthode d'installation peuvent documenter l'intention; amélioration de la lisibilité. Donc, personnellement, je vous soutiens.
C'est différent d'un test qui appelle d'autres tests - ce qui est mauvais. Pas d'isolement de test. Un test ne devrait pas influencer le résultat d'un autre test.

Bien que ce ne soit pas un cas d'utilisation freq, j'utilise parfois Asserts dans une méthode de configuration pour que je puisse savoir si la configuration du test n'a pas eu lieu comme je le pensais; généralement quand je traite des composants que je n'ai pas écrit moi-même. Un échec d'assertion qui indique "Le programme d'installation a échoué!" dans l'onglet des erreurs - m'aide rapidement à intégrer le code de configuration au lieu de devoir examiner un tas de tests ayant échoué.

Un échec de l'installation devrait généralement provoquer l'échec de tous les tests de cet appareil, ce qui est une odeur que votre nez devrait bientôt capter. "Tous les tests échoués impliquent généralement que le programme d'installation a échoué" Les assertions ne sont donc pas toujours nécessaires. Cela dit, soyez pragmatique, regardez votre contexte spécifique et «Ajouter au goût».


3
2017-09-03 08:19



J'utilise les assertions Java, plutôt que celles de JUnit, dans les cas où quelque chose comme cela est nécessaire. par exemple. lorsque vous utilisez une autre classe d'utilitaire pour configurer des données de test .:

byte[] pkt = pktFactory.makePacket(TIME, 12, "23, F2");
assert pkt.length == 15;

A défaut, le système d'implication n'est pas en état de essayer pour exécuter ce test '.


3
2017-09-03 09:26