Quelqu'un peut-il expliquer l'utilisation de Python setUpet des tearDownméthodes lors de l'écriture de cas de test en dehors de celui qui setUpest appelé immédiatement avant d'appeler la méthode de test et qui tearDownest appelé immédiatement après son appel?
En général, vous ajoutez toutes les étapes prérequises à setUp et toutes les étapes de nettoyage à tearDown.
Vous pouvez en savoir plus avec des exemples ici .
Lorsqu'une méthode setUp () est définie, le testeur exécutera cette méthode avant chaque test. De même, si une méthode tearDown () est définie, le testeur invoquera cette méthode après chaque test.
Par exemple, vous avez un test qui nécessite que des éléments existent, ou certains états - vous placez donc ces actions (création d'instances d'objet, initialisation de db, préparation de règles, etc.) dans le setUp.
De plus, comme vous le savez, chaque test doit s'arrêter à l'endroit où il a été démarré - cela signifie que nous devons restaurer l'état de l'application à son état initial - par exemple, fermer les fichiers, les connexions, supprimer les éléments nouvellement créés, appeler le rappel des transactions, etc. les étapes doivent être incluses dans le tearDown.
L'idée est donc que le test lui-même ne devrait contenir que les actions à effectuer sur l'objet de test pour obtenir le résultat, tandis que setUp et tearDown sont les méthodes pour vous aider à laisser votre code de test propre et flexible.
Vous pouvez créer un setUp et un tearDown pour un tas de tests et les définir dans une classe parent - il vous serait donc facile de prendre en charge ces tests et de mettre à jour les préparations et nettoyages courants.
Si vous recherchez un exemple simple, veuillez utiliser le lien suivant avec un exemple
Vous pouvez les utiliser pour éliminer le code commun à tous les tests de la suite de tests.
Si vous avez beaucoup de code répété dans vos tests, vous pouvez les raccourcir en déplaçant ce code vers setUp / tearDown.
Vous pouvez l'utiliser pour créer des données de test (par exemple, configurer des faux / simulacres), ou supprimer des fonctions avec des faux.
Si vous effectuez des tests d'intégration, vous pouvez utiliser les conditions préalables de vérification de l'environnement dans setUp et ignorer le test si quelque chose n'est pas configuré correctement.
Par exemple:
class TurretTest(unittest.TestCase):
def setUp(self):
self.turret_factory = TurretFactory()
self.turret = self.turret_factory.CreateTurret()
def test_turret_is_on_by_default(self):
self.assertEquals(True, self.turret.is_on())
def test_turret_turns_can_be_turned_off(self):
self.turret.turn_off()
self.assertEquals(False, self.turret.is_on())
Supposons que vous ayez une suite avec 10 tests. 8 des tests partagent le même code de configuration / démontage. Les 2 autres ne le font pas.
La configuration et le démontage vous offrent un bon moyen de refactoriser ces 8 tests. Maintenant, que faites-vous des 2 autres tests? Vous les déplaceriez vers un autre testcase / suite. Ainsi, l'utilisation de la configuration et du démontage permet également de donner un moyen naturel de diviser les tests en cas / suites
la source