web-dev-qa-db-fra.com

Comment séparer les tests unitaires et les tests d'intégration dans Pytest

Selon Wikipedia et divers articles il est préférable de diviser les tests en tests unitaires (exécuter en premier) et tests d'intégration (exécuter en second), où les tests unitaires sont généralement très rapides et doit être exécuté avec chaque génération dans un environnement CI, mais les tests d'intégration prennent plus de temps à exécuter et doivent être plus quotidiens.

Existe-t-il un moyen de les diviser en pytest? La plupart des projets ne semblent pas avoir plusieurs dossiers de test, donc y a-t-il un moyen de m'assurer que je n'exécute que Unit, Integration ou les deux selon la situation (CI vs builds quotidiens)? Lors du calcul de la couverture du test, je suppose que je devrai exécuter les deux.

Est-ce que j'y vais de la bonne façon en essayant de diviser les tests en ces catégories? Y a-t-il un bon exemple quelque part d'un projet qui a fait cela?

pythonunit-testingtestingintegration-testingpytest
10
Harlekuin

Oui, vous pouvez marquer les tests avec le pytest.mark décorateur.

Exemple:

def unit_test_1():
    # assert here

def unit_test_2():
    # assert here

@pytest.mark.integtest
def integration_test():
    # assert here

Maintenant, à partir de la ligne de commande, vous pouvez exécuter pytest -m "not integtest" pour les tests unitaires uniquement, pytest -m integtest uniquement pour le test d'intégration et plain pytest pour tous.

(Vous pouvez également décorer vos tests unitaires avec pytest.mark.unit si vous voulez, mais je trouve ça un peu fastidieux/verbeux)

Voir documentation pour plus d'informations.

15
gmds

Vous pouvez également physiquement séparer les tests unitaires et d'intégration dans des répertoires spécifiques. Voici un exemple de structure de fichier de A. Shaw's article Premiers pas avec les tests en Python :

enter image description here

Avec une approche structurelle:

  1. vous n'avez pas besoin de marquer manuellement divers tests avec des attributs ou @pytest.mark
  2. vous n'êtes pas limité à un testeur spécifique. Exemples, tirés du project/ répertoire:

Avec unittest de la bibliothèque standard:

> python -m unittest discover -s tests/integration

Avec nose:

> nose tests/integration

Avec pytest :

> pytest tests/integration

De nombreux lanceurs de tests ont un mécanisme de découverte de test automatique qui peut trouver des tests dans des sous-répertoires, par ex.

> cd <root_dir>
> pytest project/
7
pylang