Présentation des tests en Python. 2e partie

Bonjour à tous!

Nous continuons l' article sur la connaissance des tests en Python, que nous avons préparé pour vous dans le cadre de notre cours de développeur Python .

Test pour Django et Flask Web Framework

Si vous écrivez des tests pour des applications Web à l'aide de l'un des frameworks populaires, par exemple, Django ou Flask, il convient de se rappeler les différences importantes dans l'écriture et l'exécution de ces tests.

Comment ils diffèrent des autres applications

Pensez au code que vous souhaitez tester dans une application Web. Tous les itinéraires, vues et modèles nécessitent beaucoup d'importations et de connaissances sur le cadre utilisé.
Cela est similaire au test d'une voiture, qui a été discuté dans la première partie du didacticiel: avant d'effectuer des tests simples, tels que la vérification des phares, vous devez allumer l'ordinateur dans la voiture.

Django et Flask simplifient cette tâche et fournissent un cadre de test basé sur unittittest. Vous pouvez continuer à écrire des tests de la manière habituelle, mais exécutez-les un peu différemment.



Comment utiliser le Django Test Executor

Le modèle Django startapp crée le fichier tests.py dans votre répertoire d'application. S'il n'est pas déjà là, créez-le avec le contenu suivant:

from django.test import TestCase class MyTestCase(TestCase): # Your test methods 

La principale différence avec les exemples précédents est que vous devez hériter de django.test.TestCase , et non unittest.TestCase . L'API de ces classes est la même, mais la classe Django TestCase configure tout pour les tests.

Pour exécuter une suite de tests, utilisez le test manage.py au lieu de unittest sur la ligne de commande:

 $ python manage.py test 

Si vous avez besoin de plusieurs fichiers de test, remplacez tests.py par le dossier tests, placez-y un fichier vide appelé __init__.py et créez test_*.py fichiers test_*.py . Django les détectera et les exécutera.

Plus d'informations sont disponibles sur le site de documentation de Django .

Comment utiliser Unittest et Flask

Pour fonctionner avec Flask, une application doit être importée et mise en mode test. Vous pouvez créer un client de test et l'utiliser pour envoyer des demandes à toutes les routes de votre application.

Le client de test est instancié dans la méthode setUp de votre scénario de test. Dans l'exemple suivant, my_app est le nom de l'application. Ne vous inquiétez pas si vous ne savez pas ce que fait la configuration. Nous examinerons de plus près la section "Scripts de test plus avancés".
Le code du fichier de test ressemblera à ceci:

 import my_app import unittest class MyTestCase(unittest.TestCase): def setUp(self): my_app.app.testing = True self.app = my_app.app.test_client() def test_home(self): result = self.app.get('/') # Make your assertions 

Vous pouvez ensuite exécuter des cas de test à l'aide de la commande python -m unittest discover.

Plus d'informations sont disponibles sur le site de documentation de Flask.

Scripts de test plus avancés

Avant de commencer à créer des tests pour votre application, n'oubliez pas les trois étapes principales de tout test:

1. Création de paramètres d'entrée;
2. Exécution de code, réception de données de sortie;
3. Comparaison des données de sortie avec le résultat attendu;

Cela peut être plus compliqué que de créer une valeur statique pour les données source comme une chaîne ou un nombre. Parfois, votre application nécessite une instance d'une classe ou d'un contexte. Que faire dans ce cas?

Les données que vous créez en tant que source sont appelées fixture. La création et la réutilisation de luminaires est une pratique courante.

L'exécution du même test plusieurs fois avec des valeurs différentes en prévision du même résultat est appelée paramétrage.

Gestion des échecs attendus

Plus tôt, lorsque nous avons compilé une liste de scripts pour tester sum() , la question s'est posée: que se passe-t-il lorsque nous fournissons une mauvaise valeur, par exemple, un seul entier ou une chaîne?

Dans ce cas, il est prévu que sum() génère une erreur. Si une erreur se produit, le test échouera.

Il existe un moyen spécifique de gérer les erreurs attendues. Vous pouvez utiliser .assertRaises() comme gestionnaire de contexte, puis effectuer des étapes de test à l'intérieur du bloc with :

 import unittest from my_sum import sum class TestSum(unittest.TestCase): def test_list_int(self): """ ,       """ data = [1, 2, 3] result = sum(data) self.assertEqual(result, 6) def test_list_fraction(self): """ ,       """ data = [Fraction(1, 4), Fraction(1, 4), Fraction(2, 5)] result = sum(data) self.assertEqual(result, 1) def test_bad_type(self): data = "banana" with self.assertRaises(TypeError): result = sum(data) if __name__ == '__main__': unittest.main() 

Ce cas de test ne sera réussi que si sum(data) lève une TypeError. Vous pouvez remplacer TypeError par tout autre type d'exception.

Isolement du comportement des applications

Dans la dernière partie du tutoriel, nous avons parlé des effets secondaires. Ils compliquent les tests unitaires, car chaque test peut produire un résultat différent ou pire - un test peut affecter l'état de l'application entière et entraîner l'échec d'un autre test!

Il existe quelques techniques simples pour tester des parties d'une application avec beaucoup d'effets secondaires:

• Refactorisation du code conformément au principe de responsabilité unique;
• Se moquer de toutes les méthodes et appels de fonction pour éliminer les effets secondaires;
• Utilisation de tests d'intégration au lieu de tests unitaires pour ce fragment de l'application.
• Si vous n'êtes pas familier avec le moking, consultez quelques excellents exemples de test CLI Python .

Écriture de tests d'intégration

Jusqu'à présent, nous avons accordé plus d'attention aux tests unitaires. Les tests unitaires sont un excellent moyen de créer du code prévisible et stable. Mais au final, votre application devrait fonctionner au démarrage!

Des tests d'intégration sont nécessaires pour vérifier la collaboration de plusieurs composants d'application. Ces tests peuvent nécessiter de jouer le rôle de l'acheteur ou de l'utilisateur:

• Appelez l'API HTTP REST;
• Appel API Python;
• Appel de service Web;
• Exécutez la ligne de commande.

Tous ces types de tests d'intégration peuvent être écrits de la même manière que les tests unitaires, en suivant le modèle Paramètres d'entrée, exécution, approbation. La différence la plus significative est que les tests d'intégration testent simultanément plus de composants, ce qui signifie qu'ils entraîneront plus d'effets secondaires que les tests unitaires. De plus, les tests d'intégration nécessitent plus d'appareils, tels qu'une base de données, une prise réseau ou un fichier de configuration.

Par conséquent, il est recommandé de séparer les tests unitaires et les tests d'intégration. La création d'appareils pour l'intégration, par exemple, une base de données de test ou des cas de test eux-mêmes, prend beaucoup plus de temps que d'effectuer des tests unitaires, vous devez donc effectuer des tests d'intégration avant de passer en production au lieu de les exécuter chaque fois que vous vous engagez.

Le moyen le plus simple de séparer les tests unitaires et d'intégration est de les placer dans des dossiers différents.

project/
│
├── my_app/
│ └── __init__.py
│
└── tests/
|
├── unit/
| ├── __init__.py
| └── test_sum.py
|
└── integration/
├── __init__.py
└── test_integration.py

Vous pouvez exécuter un groupe spécifique de tests de différentes manières. Un indicateur pour spécifier le répertoire source, -s, peut être ajouté à la découverte la plus simple avec un chemin contenant des tests:

 $ python -m unittest discover -s tests/integration 

unittest affichera tous les résultats dans le répertoire tests / intégration.

Test des applications orientées données

De nombreux tests d'intégration nécessitent des données dorsales, telles qu'une base de données avec des valeurs spécifiques. Supposons que vous ayez besoin d'un test pour vérifier le bon fonctionnement de l'application avec plus de 100 clients dans la base de données, ou pour vérifier l'exactitude de l'affichage de la page de commande, même si tous les noms des marchandises sont en japonais.

Ces types de tests d'intégration dépendront de divers montages de test pour assurer leur répétabilité et leur prévisibilité.

Les données de test doivent être stockées dans le dossier fixtures à l'intérieur du répertoire des tests d'intégration pour souligner leur «testabilité». Ensuite, dans les tests, vous pouvez charger les données et exécuter le test.

Voici un exemple de structure de données composée de fichiers JSON:

project/
│
├── my_app/
│ └── __init__.py
│
└── tests/
|
└── unit/
| ├── __init__.py
| └── test_sum.py
|
└── integration/
|
├── fixtures/
| ├── test_basic.json
| └── test_complex.json
|
├── __init__.py
└── test_integration.py

Dans le cas de test, vous pouvez utiliser la méthode .setUp () pour charger les données de test à partir du fichier fixture d'une manière connue et exécuter plusieurs tests avec ces données. N'oubliez pas que vous pouvez stocker plusieurs cas de test dans un fichier Python, unittest les trouvera et les exécutera. Vous pouvez avoir un cas de test pour chaque ensemble de données de test:

 import unittest class TestBasic(unittest.TestCase): def setUp(self): # Load test data self.app = App(database='fixtures/test_basic.json') def test_customer_count(self): self.assertEqual(len(self.app.customers), 100) def test_existence_of_customer(self): customer = self.app.get_customer(id=10) self.assertEqual(customer.name, "Org XYZ") self.assertEqual(customer.address, "10 Red Road, Reading") class TestComplexData(unittest.TestCase): def setUp(self): # load test data self.app = App(database='fixtures/test_complex.json') def test_customer_count(self): self.assertEqual(len(self.app.customers), 10000) def test_existence_of_customer(self): customer = self.app.get_customer(id=9999) self.assertEqual(customer.name, u"バナナ") self.assertEqual(customer.address, "10 Red Road, Akihabara, Tokyo") if __name__ == '__main__': unittest.main() 

Si votre application dépend des données d'un emplacement distant, comme une API distante, assurez-vous que les tests sont répétables. Le développement peut être retardé en raison d'échecs de tests lors de la désactivation de l'API et de problèmes de communication. Dans de tels cas, il est préférable de stocker localement les appareils distants pour être rappelé et envoyé à l'application.

La bibliothèque de requests dispose d'un package de réponses gratuit qui vous permet de créer des fixtures de réponse et de les enregistrer dans des dossiers de test. En savoir plus sur leur page GitHub .

La prochaine partie portera sur les tests dans plusieurs environnements et les tests d'automatisation.

LA FIN

Les commentaires / questions sont toujours les bienvenus. Ici ou allez à Stas lors d'une journée portes ouvertes .