Regardez un rapport JUnit. JUnit est déjà organisé par package. Chaque package a (ou peut avoir) des classes TestSuite, chacune exécutant à son tour plusieurs TestCases. Chaque TestCase peut avoir plusieurs méthodes de test du formulairepublic void test*()
, chacune devenant en fait une instance de la classe TestCase à laquelle elles appartiennent. Chaque méthode de test (instance TestCase) a un nom et un critère de réussite / échec.
Ce dont ma direction a besoin, c'est du concept de TestStep individuel éléments , chacun indiquant ses propres critères de réussite / échec. L'échec d'une étape de test ne doit pas empêcher l'exécution des étapes de test suivantes.
Dans le passé, les développeurs de tests à ma place organisaient les classes TestCase en packages correspondant aux parties du produit testé, créaient une classe TestCase pour chaque test et faisaient de chaque méthode de test une "étape" distincte du test, complet avec ses propres critères de réussite / échec dans la sortie JUnit. Chaque TestCase est un "test" autonome, mais les méthodes individuelles, ou "étapes" de test dans le TestCase, doivent se produire dans un ordre spécifique.
Les méthodes TestCase étaient les étapes de TestCase, et les concepteurs de tests ont obtenu un critère de réussite / échec distinct par étape de test. Maintenant, les étapes du test sont mélangées et les tests échouent (bien sûr).
Par exemple:
Class testStateChanges extends TestCase
public void testCreateObjectPlacesTheObjectInStateA()
public void testTransitionToStateBAndValidateStateB()
public void testTransitionToStateCAndValidateStateC()
public void testTryToDeleteObjectinStateCAndValidateObjectStillExists()
public void testTransitionToStateAAndValidateStateA()
public void testDeleteObjectInStateAAndObjectDoesNotExist()
public void cleanupIfAnythingWentWrong()
Chaque méthode de test affirme et signale ses propres critères de réussite / d'échec. Réduire cela en "une seule grande méthode de test" pour les besoins de la commande perd la granularité des critères de réussite / échec de chaque "étape" dans le rapport de synthèse JUnit. ... et cela dérange mes managers. Ils réclament actuellement une autre alternative.
Quelqu'un peut-il expliquer comment une unité JUnit avec un ordre de méthode de test brouillé prendrait en charge des critères de réussite / échec distincts pour chaque étape de test séquentielle, comme illustré ci-dessus et requis par ma direction?
Quelle que soit la documentation, je vois cela comme une sérieuse régression dans le framework JUnit qui rend la vie difficile à de nombreux développeurs de tests.