Est-il possible d'exclure les répertoires de test des rapports coverage.py ?

Question

Je suis un peu un débutant avec les tests unitaires en python, et en particulier coverage.py. Est-il souhaitable que les rapports de couverture incluent la couverture de vos fichiers de test réels ?

Voici une capture d'écran de mon Rapport HTML à titre d'exemple.

Vous pouvez constater que le rapport comprend tests/test_credit_card . Au début, j'essayais d'omettre le tests/ à partir des rapports, comme suit :

coverage html --omit=tests/ -d tests/coverage

J'ai essayé plusieurs variantes de cette commande, mais je n'ai pas pu pas Je n'arrive pas à trouver les tests/exclusions. Après avoir accepté la défaite, j'ai commencé à me demander si les fichiers de test ne sont pas supposé à inclure dans le rapport.

Quelqu'un peut-il nous éclairer à ce sujet ?

Answer 1

coverage html --omit="*/test*" -d tests/coverage

Answer 2

Créer .coveragerc dans le dossier racine de votre projet, et inclure ce qui suit :

[run]
omit = *tests*

Answer 3

Je le laisse ici au cas où un développeur Django aurait besoin d'un .coveragerc pour son projet.

[run]
source = .
omit = ./venv/*,*tests*,*apps.py,*manage.py,*__init__.py,*migrations*,*asgi*,*wsgi*,*admin.py,*urls.py

[report]
omit = ./venv/*,*tests*,*apps.py,*manage.py,*__init__.py,*migrations*,*asgi*,*wsgi*,*admin.py,*urls.py

Créez un fichier nommé .coveragerc dans le répertoire racine de votre projet, collez le code ci-dessus et exécutez la commande :

coverage run manage.py test

En outre, si vous souhaitez que les tests s'exécutent plus rapidement, exécutez plutôt cette commande.

coverage run manage.py test --keepdb --parallel

Cela permet de préserver la base de données de test et d'exécuter les tests en parallèle.

Answer 4

Vous pouvez spécifier les répertoires que vous souhaitez exclure en créant un fichier .coveragerc dans le projet Root.

Il prend en charge les caractères génériques (que vous pouvez utiliser pour exclure un environnement virtuel). y les commentaires (très utiles pour un suivi efficace).

Le bloc de code ci-dessous montre comment omit peuvent être utilisées (extraites de la base de données dernière documentation ) avec plusieurs fichiers et répertoires.

[run]
omit =
    # omit anything in a .local directory anywhere
    */.local/*
    # omit everything in /usr
    /usr/*
    # omit this single file
    utils/tirefire.py

Dans votre cas, vous pourriez avoir les éléments suivants dans votre .coveragerc :

[run]
omit = 
    # ignore all test cases in tests/
    tests/*

En ce qui concerne votre question sur les rapports de couverture, vous pouvez envisager les tests et la couverture de la manière suivante :

• Lorsque vous exécutez pytest o unittest tous les cas de test de votre code source sont exécutés

• Lorsque vous exécutez coverage Il montre la partie du code source qui n'est pas utilisée.

• Lorsque vous exécutez pytest avec une couverture (quelque chose comme pytest -v --cov ), il exécute tous les cas de test y montre la partie du code source qui n'est pas utilisée.

Extra :

• Vous pouvez également spécifier l'emplacement de votre rapport HTML dans le fichier de configuration :

  [html] directory = tests/coverage/html_report/

Cela va créer html , js , css etc. à l'intérieur tests/coverage/html_report/ chaque fois que vous courez coverage o pytest -v --cov

Answer 5

C'est une bonne idée de voir la couverture de vos tests car elle peut mettre en évidence des problèmes. Si votre code de test n'est pas exécuté, c'est qu'il n'était pas utile de l'écrire !

Le cas le plus fréquent est celui où je donne le même nom à deux fonctions de test d'unité - j'ajoute un nouveau test plusieurs mois après l'original et il se trouve que je choisis le même nom. Le framework unittest ne s'en plaindra pas - l'une des fonctions cache l'autre et il n'exécutera pas l'un des tests ! Le rapport de couverture détaillé montre le problème immédiatement.

Si vous avez d'autres codes dans vos tests qui ne sont pas exécutés, cela peut également indiquer d'autres bogues, bien qu'il y ait souvent quelques lignes de code standard qui peuvent ne pas être couvertes en fonction de la façon dont les tests sont invoqués, alors ne soyez pas obsédé par l'idée d'atteindre 100 %.

Et si vous avez du code de test qui n'est vraiment plus nécessaire, il est toujours bon de le supprimer !