web-dev-qa-db-fra.com

Django setUpTestData () vs setUp ()

Django 1.8 est livré avec ne TestCase refactorisée qui permet l'initialisation des données au niveau de la classe en utilisant des transactions et des points de sauvegarde via la méthode setUpTestData () . Ceci contraste avec le setUp () de unittest qui s'exécute avant chaque méthode de test.

Question: Quel est le cas d'utilisation de setUp() dans Django maintenant que setUpTestData() existe?

Je recherche uniquement des réponses objectives et de haut niveau, sinon cette question serait trop large pour Stack Overflow.

pythondjangounit-testing
47
rnevius

Il n'est pas rare qu'il y ait du code de configuration qui ne peut pas s'exécuter en tant que méthode de classe. Un exemple notable est le Django client de test : vous ne voudrez peut-être pas réutiliser la même instance de client à travers des tests qui partagent sinon une grande partie des mêmes données, et en effet, le les instances client automatiquement incluses dans les sous-classes de SimpleTestCase de Django sont créées par méthode de test plutôt que pour la classe entière. Supposons que vous ayez eu un test du monde pré-Django 1.8 avec un setUp méthode comme celle-ci:

 def setUp (self): 
 self.the_user = f.UserFactory.create () 
 self.the_post = f.PostFactory.create (author = self.the_user) 
 self.client.login (
 username = self.the_user.username, password = TEST_PASSWORD 
) 
 # ... & c.

Vous pourriez être tenté de moderniser le scénario de test en remplaçant setUp par setUpTestData, en giflant un @classmethod décorateur en haut et en changeant tous les selfs en cls. Mais cela échouera avec un AttributeError: type object 'MyTestCase' has no attribute 'client'! À la place, vous devez utiliser setUpTestData pour les données partagées et setUp pour le client par méthode de test:

 @classmethod 
 def setUpTestData (cls): 
 cls.the_user = f.UserFactory.create () 
 cls.the_post = f.PostFactory.create (auteur = cls.the_user) 
 # ... & c. 
 
 def setUp (self): 
 self.client.login (
 username = self.the_user.username, password = TEST_PASSWORD 
)

Remarque: si vous vous demandez ce que fait cette variable f dans l'exemple de code, cela vient de factoryboy - un appareil utile bibliothèque pour créer des objets pour vos tests.

40
Zack M. Davis

Tiré de ce tutoriel de test: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Testing#Views

setUpTestData () est appelé une fois au début du test pour la configuration au niveau de la classe. Vous utiliseriez cela pour créer des objets qui ne seront pas modifiés ou changés dans aucune des méthodes de test.

setUp () est appelé avant chaque fonction de test pour configurer les objets qui peuvent être modifiés par le test (chaque fonction de test obtiendra une version "fraîche" de ces objets).

12
user2052130

Problèmes de caches. Même si Django réussit mieux à fournir l'isolement de test avec la restauration des transactions, les caches sont toujours générés et effacés manuellement.

[edit]: SetUpTestData définit l'état dans lequel la base de données sera restaurée après chaque test, et le fait avec une méthode qui n'est exécutée qu'une seule fois, l'annulation de transaction étant effectuée derrière le rideau par Django. Cela ne fonctionne pas pour les caches. Si vous souhaitez que le cache soit le même pour chaque test, vous devez le réinitialiser entre chaque test, d'où la nécessité d'une configuration. Django peut restaurer la base de données mais ne peut pas tout restaurer.

(Merci bryan-oakley pour la suggestion)

4
Joachim Jablon