web-dev-qa-db-fra.com

Écriture de cas de test pour les modèles Django

À mi-chemin de mon projet actuel, après avoir souffert de la peine de passer un nombre incalculable de minutes sur le débogage, j'ai décidé d'adopter TDD. Pour commencer, je prévois d'écrire un ensemble de tests unitaires pour chaque modèle existant. Mais pour les modèles qui n'ont que des attributs définis (c'est-à-dire pas de méthodes/propriétés supplémentaires), je ne sais pas ce que je dois tester ni comment.

class Product(models.Model):
    name = models.CharField(max_length=50)
    description = models.TextField(default='', blank=True)
    retails = models.ManyToManyField(Retail, verbose_name='Retail stores that carry the product')
    manufacturer = models.ForeignKey(Manufacturer, related_name='products')
    date_created = models.DateTimeField(auto_now_add=True)
    date_modified = models.DateTimeField(auto_now=True)

En utilisant Produit comme exemple, quelles sont les choses à ce sujet que les tests unitaires devraient couvrir? Et comment couvrir ForeignKey et ManyToManyField?

pythondjangodjango-modelsdjango-testing
38
tamakisquare

C'était un article que j'ai trouvé utile: http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-Django/ . Voici un bon résumé de ce qu'il faut tester:

Un autre revers courant pour les développeurs/concepteurs débutants dans les tests est la question "que dois-je (ou ne dois-je pas) tester? Bien qu'il n'y ait pas de règles strictes et rapides qui s'appliquent parfaitement partout, il y a quelques directives générales que je peux offrir pour prendre la décision:

  • Si le code en question est une fonction/bibliothèque intégrée Python, ne la testez pas. Des exemples comme la bibliothèque datetime.

  • Si le code en question est intégré à Django, ne le testez pas. Des exemples tels que les champs d'un modèle ou tester la façon dont le modèle intégré.Node rend les balises incluses.

  • Si votre modèle possède des méthodes personnalisées, vous devez le tester, généralement avec des tests unitaires.

  • Il en va de même pour les vues personnalisées, les formulaires, les balises de modèle, les processeurs de contexte, le middleware, les commandes de gestion, etc. Si vous avez implémenté la logique métier, vous devez tester vos aspects du code.

Donc, pour votre exemple, il n'y aurait vraiment rien à tester tant que vous n'aurez pas écrit de fonctions personnalisées.
À mon avis, tester les liens ForeignKey et ManyToManyField relèverait de la deuxième catégorie (code intégré à Django), donc je ne les testerais pas, car vous testez vraiment si oui ou non Django fonctionne correctement. Si vous avez une méthode qui crée une instance de votre produit, y compris des relations étrangères et des M2M, vous pouvez vérifier que les données ont été créées, ce serait tester votre méthode personnalisée, pas Django fonctionnalité.

En utilisant le paradigme TDD, les tests sont construits pour vérifier la logique métier et les exigences de conception.

77
Furbeenator

Mon TDD de classe CS350 stipulait qu'il était préférable de tester tous les accesseurs et mutateurs. Donc, pour un modèle, vous devez d'abord écrire des tests qui appellent chaque fonction d'évaluateur et vous assurer qu'il renvoie la valeur appropriée.

Pour chaque fonction qui modifie un champ de données dans le modèle, vous testeriez non seulement le résultat de ce champ de données en particulier, mais vous testeriez également tous les autres champs de l'instance de modèle pour vous assurer qu'aucun d'entre eux n'a été modifié par erreur. .

Pour reformater :, si un modèle a les champs a, b et c, vous créeriez une instance à l'aide de votre constructeur, puis l'actif que les trois sont correctement définis. Disons qu'il y a une autre fonction, set_a (). Vous affirmeriez que non seulement la valeur de "a" a changé, mais que les valeurs de b et c restent inchangées.

0
dahifi