Luminaires de style pytest xUnit – Tests Python

By | août 9, 2019

Formation gratuite Python

Je vais aborder la syntaxe de prise en charge de pytest pour les fixtures de style xUnit.
Ensuite, je donnerai un exemple plus raisonnable et typique, en utilisant un seul ensemble de fonctions d’appareil.
Et abordez ensuite la question de la mixité des tests dans un fichier. Certains qui ont besoin de la ressource, d'autres pas.

En fonction de l’étendue que vous souhaitez pour vos appareils, vous définissez des paires configuration / démontage.

  • Module (setup_module / teardown_module)
    • Met les choses en place une fois pour le module, démonte après tout.
  • Fonction (setup_function / teardown_function)
    • Enveloppe chaque fonction de test avec des appels.
    • Se fait appeler plusieurs fois, une fois pour chaque fonction
  • Classe (setup_class / teardown_class)
    • Comme au niveau du module, mais pour les classes, une fois pour une classe.
  • Méthode (setup_method / teardown_method)
    • Comme le niveau de fonction, mais pour les classes.
    • Se fait appeler plusieurs fois, une fois pour chaque méthode de test dans une classe

Exemple utilisant des fixtures de module, fonction, classe et méthode

Et laisse courir pour voir le flux. J'ai supprimé certaines des lignes vierges supplémentaires pour ce poste.

Exemple réaliste

En règle générale, vous ne combinez pas tous les types de projecteurs.
La plupart du temps, un seul style suffit, selon ce que vous configurez, initialisez, etc., et s'il doit être réinitialisé avant chaque test et nettoyé après chaque test.

Alors, rendons les choses un peu plus simples.

J'ai une ressource appelée resource_a. Je sais, nom ennuyeux. C’est juste quelque chose qui nécessite une configuration et une fonction de démontage.

Cela pourrait vraiment être n'importe quelle ressource:

  • fichier temporaire
  • répertoire temporaire
  • connexion à la base de données
  • transaction db qui doit être annulée après les tests
  • connexion prise ouverte
  • un générateur de signal émettant un signal de test
  • vous obtenez la dérive

Dans cet exemple, j’ai utilisé des fixtures de niveau méthode afin que la configuration / le démontage ait lieu au début et à la fin du module, une fois pour tous les tests. C’est peut-être une opération coûteuse ou quelque chose du genre.

Voici notre exemple plus simple avec une ressource.

Et la sortie.

Ajout d'une autre fonction de test

Ensuite, nous ajoutons un test qui n’a pas besoin de la ressource:

Et nous le relançons.

Ce n’est pas vraiment un problème jusqu’à présent.
Comme le premier test a besoin de la ressource, la manière dont nous procédons est satisfaisante.

Problème: la ressource est configurée même lorsque nous n’en avons pas besoin.

Si nous voulons seulement exécuter une fonction, la deuxième, qui n’a pas besoin de la ressource, le projecteur est exécuté de toute façon.

C'est un gaspillage.
Si les montages sont assez longs, le test peut être sérieusement ralenti inutilement.

Création de classes pour séparer les besoins de fixtures

Vous pouvez résoudre ce problème de manière relativement propre en isolant les tests nécessitant une ressource dans leur propre module ou dans leur propre classe.

Je vais démontrer la solution de classe à ce problème.

Déplacez les fixtures du niveau du module au niveau de la classe et déplacez les tests qui utilisent la ressource dans la classe.

Maintenant, nous pouvons exécuter le test de manière isolée sans configuration / nettoyage coûteux et inutile des ressources.

Et la ressource est toujours traitée correctement lorsque nous en avons besoin.

Dans bien des cas, la gestion des ressources de cette manière est tout à fait suffisante.

Cependant, j'estime que le mécanisme de montage pytest (que je traiterai dans mon prochain article) est une solution plus élégante et évolutive au problème.