Je sais que, dans l'automatisation des tests, nous devons éviter les cas de test séquentiels . Ainsi, l'ordre d'exécution des cas de test n'est pas important.
Je crois que dans certains cas, les cas de test séquentiels sont inévitables:
1. Considérez un scénario dans lequel un utilisateur doit effectuer certaines étapes précédentes afin d'atteindre un objectif final. Par exemple, un utilisateur doit être connecté pour pouvoir acheter.
Given User is logged in When User adds an item into its basket And User Complete his purchase Then He receives an Email
Ainsi, dans le scénario ci-dessus, chaque partie ( Donnée , Quand , Et , ou Then ) sont des cas de test séparés. Mais l'ordre du testcase est toujours crucial.
2.L'équipe Junit fournit également une méthode appelée @FixMethodOrder (MethodSorters.NAME_ASCENDING) pour une telle utilisation, mais je ne sais pas quand nous sommes autorisés à utiliser cela?
Alors, comment rédigez-vous des cas de test indépendants dans les tests de bout en bout?
3 Réponses :
Les tests sont censés être atomiques, dans le sens où ils ne doivent PAS s'appuyer sur un statut généré par un test précédent. C'est pourquoi les cas de test séquentiels doivent être évités. Dans le cas où une partie de la séquence échoue, alors le reste des tests échoue, donc cela n'a vraiment pas beaucoup de sens de les séparer (ils pourraient être juste un test).
Si vous avez besoin de conditions préalables pour vos tests, vous pouvez les inclure dans: 1) avant tous les tests, 2) au début de la suite de tests, 3) avant votre test spécifique, 4) dans votre test spécifique. Peu importe où / quand cela est fait, l'important est que vous supposiez que tout ce qui est nécessaire pour générer ce statut fonctionne comme prévu, donc vous vous concentrez uniquement sur ce que vous testez.
Maintenant, si vous voulez tester un flux complet d'un système, je vous recommande de le mettre dans un seul test. Au cas où il y aurait des variations, vous auriez alors plusieurs tests.
Disons par exemple que vous voulez tester D, mais D a besoin de C, puis C a besoin de B, et finalement B a besoin de A; une stratégie serait de générer un test dans lequel vous feriez A-> B-> C-> D. Une autre stratégie consiste à générer plusieurs tests dans lesquels vous testez les étapes individuelles: le test 1 fait A; le test 2 fait A-> B (mais ne se soucie pas si A est ok); le test 3 fait A-> B-> C (mais ne se soucie pas si A et B sont ok); etc. La stratégie à utiliser dépendra de vos objectifs et de la taille du scénario. Personnellement, je préfère la deuxième option pour les grandes choses, et la première pour les simples / courtes.
Le cadre de test de l'interface utilisateur espresso permet de mettre en œuvre de tels scénarios de parcours utilisateur-core .
Si vous voulez des tests unitaires, vous devez définir les conditions préalables attendues au début de chacun.
Le dicton "éviter les cas de test séquentiels" ne s'applique qu'aux tests unitaires. Et c'est là que brillent Junit et mockito. Dans ces cas, nous nous inquiétons uniquement de l'exactitude de une unité . Nous ne nous soucions pas de l'échec ou de la réussite des autres unités, nous nous moquerons des autres comportements des unités, afin de pouvoir nous concentrer sur le test des comportements exacts du test actuel.
Le cas que vous avez décrit n'entre pas dans cette catégorie. Dans votre cas, vous avez besoin d'une suite de tests d'intégration car vous devez tester le flux de bout en bout. Vous pouvez utiliser les outils suivants pour le test d'intégration.