fixations de pytest

By | août 9, 2019

Formation Python

J'aimerais terminer cette récente série d'articles sur les appareils Pytest en présentant ma version d'une sorte de référence.
Comme ce message est un peu long, voici quelques liens vers le contenu enfoui ici.

Puisque je prévois d’utiliser cette référence pour ma propre référence, je vais ajouter quelques liens ici, en haut, à des éléments qui me semblent utiles en ce qui concerne les appareils les plus fiables.

Et… pendant que je lance des liens, voici les autres articles de la série:

J'essaie de garder les exemples dans ce post genre de petite-ish.
Cependant, je risque d'être trop concis. (ou trop verbeux).
Il est également possible que l’ordre que j’ai énoncé soit étrange. J'ai fait beaucoup de copier / coller à partir de l'éditeur de code et de la fenêtre bash pour mettre ce message en ligne.

S'il vous plaît, faites-moi savoir:

  • si j’ai perdu un copier / coller et qu’il ya quelque chose de bizarre ici.
  • si j’ai été trop concis ou incertain.
  • si ce que je dis est complètement faux. Surtout celui-ci
  • si vous avez réellement atteint la fin sans vouloir vouloir me jeter quelque chose.

Note sur le code commun

Pour tous les exemples, le fichier de test que j’exécute a ceci en haut:

Cependant, je ne vais pas le copier dans tous les blocs de code ci-dessous.
Je lance également chaque exemple avec:

Exemple d'os nus

Voici un appareil super basique et quelques tests l’utilisant.

Avec les paramètres par défaut de ‘pytest.fixture ()’, l’appareil va être appelé pour chaque test nommant cet appareil dans sa liste de paramètres.
Sortie:

Trois façons d'utiliser un appareil

  1. nomme le du test.
    Juste comme le top exemple
  2. décorateur de fixations
    Vous pouvez marquer un test ou une classe de tests avec ‘pytest.mark.usefixtures () 'et inclure une liste des fixtures à utiliser avec le test ou la classe de tests.
    Ceci est particulièrement pratique pour les classes de test.
    Il est également utile, lors de la conversion de classes unittest, d’utiliser des appareils pytest.
    Je vais donner un exemple sous peu.
  3. autouse
    Puissant, mais éventuellement dangereux.
    Couvert dans la section suivante.

Exemple d'utilisation

Voici un exemple rapide du décorateur.
Le premier exemple peut être écrit comme ceci:

Ou ca:

Ou ca:

Tous avec le même effet.

Caractéristiques du luminaire

Si j’indique les paramètres par défaut de ‘pytest.fixture ()’ et j’ajoute un paramètre de requête à mon appareil, cela ressemble à ceci, mais son exécution n’est pas différente.

Voyons maintenant ces caractéristiques.

Valeur de retour

Dans cet exemple, l’appareil renvoie «Aucun».
C’est parce que c’est juste un code que je veux exécuter avant mon test, à l’instar des fonctions d’installation traditionnelles, qu’il s’agisse de nez ou de plus léger.

Cependant, vous pouvez renvoyer tout ce que vous voulez à partir de la fonction fixture.
Si votre appareil configure certaines données, lit un fichier ou ouvre une connexion à une base de données, l'accès à ces données ou ressources est ce que vous devez retourner à partir de l'appareil.

Renvoyer des données d'un fixture.

Renvoyer un objet de base de données:

Finalizer est démontage

Dans l’exemple de code précédent, l’appareil ‘cheese_db’ a ce bit de code:

La fonction «fin» agit comme le «démontage» de l’appareil.
Le nom n’a rien de spécial.
Vous pouvez le nommer "démolition", "cheese_db_teardown" ou "quelquechose_else".
Ce n'est pas grave.

Le finaliseur est appelé après tous les tests utilisant le gabarit.
Si vous avez utilisé des fixtures paramétrées, le finaliseur est appelé entre les instances des changements de fixtures paramétrées.

Portée

Scope contrôle combien de fois un appareil est appelé. La valeur par défaut est "function".
Voici les options pour la portée:

une fonction Exécuter une fois par test
classe Exécuter une fois par classe de tests
module Exécuter une fois par module
session Exécuter une fois par session

Puisque la portée par défaut est "function", l'exemple de base de données cheese ouvrira et fermera la base de données pour chaque test.

Cela n’a pas vraiment de sens. Surtout si la connexion est une opération fastidieuse.

Changer la portée:

Et répétons-le:

C'est mieux.

Demande d'objets

Dans l'exemple de fromage db, l'appareil contient un paramètre de requête. Vous avez besoin du paramètre request à un appareil pour ajouter un finaliseur.

Cependant, il a également d'autres utilisations.

Dans l’exemple ci-dessous, je montre l’utilisation (et bien, l’impression) de certains éléments. Voir API pytest pour une liste complète.

Paramètres

Un paramètre facultatif pour le décorateur de luminaires est ‘params’.
La valeur par défaut est «Aucun».

Pour chaque valeur dans params, le fixture sera appelé avec request.param renseigné avec cette valeur.
Les tests utilisant cet appareil seront appelés une fois pour chaque valeur dans params.

Exemple de jouet

Un exemple est en ordre ici.

Ce premier exemple est stupide, mais montre les mécanismes, l’utilité de l’indicateur -v et la mesure dans laquelle py.test gère les échecs des tests paramétrés.

Cela doit exécuter ‘test_not_2’ trois fois et échouer lorsque 2 est transmis.
Je vais le lancer sans et avec le drapeau -v

Exemple réel

Passons maintenant à une utilisation plus réelle du paramétrage, de l’entrée et de la sortie attendue dans le monde réel.

Voici une réécriture du test de démarques à partir du post d’introduction de pytest.
La fonction ‘run_markdown’ est un adaptateur d’API logicielle, qui prend en charge l’appel du script de démarquage sur la ligne de commande.

La sortie indique clairement que le test «test_markdown» est appelé 3 fois.
Bien entendu, les déclarations imprimées sont inutiles.
Je les ai laissés à des fins de démonstration.

Normalement, vous n'avez pas besoin des déclarations imprimées pour voir ce qui se passe.

Je vais extraire les instructions d’impression et modifier la chaîne "attendue" de la dernière valeur en entrée pour montrer comment py.test est très utile pour signaler le jeu de données qui a échoué.

sortie:

Autouse

Le paramètre facultatif du décorateur de luminaires est ‘autouse’.
La valeur par défaut est "False".

Avec la valeur ‘False’, les tests qui souhaitent utiliser le projecteur doivent soit le nommer dans leur liste de paramètres, soit faire l’objet d’un décorateur d’appareils.

Reportez-vous aux deux premiers éléments de la section «Trois façons d’utiliser un appareil» pour plus d’informations.

Avec la valeur définie sur "True", tous les tests de cette session utilisent simplement le projecteur automatiquement.

Oui, un grand pouvoir entraîne de grandes responsabilités.

Alors utilisez-le avec précaution.

Cependant, il est très pratique dans les endroits où vous auriez utilisé le style xunit setup_module

Pour notre exemple, disons simplement que j’ai un code de rapport que je voudrais utiliser en haut du module et en haut d’une fonction de test.

Les tests eux-mêmes n’ont pas besoin d’être manipulés, car ils ne renvoient aucune donnée.

sortie:

Plusieurs appareils

Dans les exemples que j'ai utilisés jusqu'à présent, seuls les tests utilisent au maximum un appareil nommé.
Vous pouvez utiliser plus.

Exemple simple:

sortie:

Modularité: appareils utilisant d'autres appareils

Les tests peuvent utiliser un ou plusieurs appareils.

Les appareils eux-mêmes peuvent également utiliser un ou plusieurs appareils.

Je vais réécrire l’exemple précédent, mais au lieu que les tests incluent tous les appareils foo, bar et baz, je les enchaînerai.

Et une autre ride, "test_two" n'inclura que "bar".

sortie

Experimental and still to cover

In this section, I’m listing the caractéristiques expérimentales, and features I haven’t fully tested and/or don’t quite understand yet.

yield_fixture

Thank you Johannes for pointed out this feature in the comments.

You can use ‘yield_fixture’ instead of the ‘fixture’ decorator for functions that yield their value rather than returning them.

The benefits are:

  • It works like a context manager.
  • You don’t have to register a teardown function via addfinalizer.
  • Therfore, you don’t have to include the request parameter just for the addfinalizer function.

Caveats:

  • It’s still "experimental", so supposedly the syntax/behavior might change in the future. As of pytest 2.7.0, it’s no longer considered experimental. It will stay.
  • Probably more, but I haven’t used it much to know what else to be careful of.

Here’s a quick example. (Yep. Staight from the comment.)

ATTENTION: My recommendation is to be aware of this feature, but use ‘addfinalizer’ for production test code.
This is a cool feature. But since it’s still listed as ‘experimental’, and I haven’t done much testing with it or testing of it, I can’t in good conscience recommend it’s use.

Hey pytest devs: Let me know if this WARNING is too strong.

I DO recommend you use it IFF you are either solo or on a small team where you are able to easily change the test code in the future if the syntax/behavior changes in future pytest releases.

ids

More information at pytest.org

I played around with this a bit, but couldn’t get anything to work.
I’m sure I was just doing something wrong.
If anyone has a working example they could share, please do.

Retour d'information

Leave a comment. Let me know if this is helpful or confusing. If you end up finding some bell or whistle of pytest fixtures that I missed, let me know.

[ad_2]