tests unitaires pour un serveur d'applications

Question

J'ai écrit un serveur d'applications (à l'aide de python & twisted) et je souhaite commencer à écrire des tests. Mais je ne veux pas utiliser la version d'essai de Twisted en raison de contraintes de temps et du manque de temps pour le jouer maintenant. Voici donc ce que j'ai à l'esprit: écrivez un petit client de test qui se connecte au serveur d'applications et effectue les requêtes nécessaires (le protocole de communication est du XML interne), stockez de manière statique le XML reçu, puis écrivez des tests. sur ces données statiques en utilisant unitest.

Ma question est la suivante: s'agit-il d'une approche correcte et, dans l'affirmative, quels types d'essais sont couverts par cette approche?

De plus, l’utilisation de cette méthode présente plusieurs inconvénients, tels que: ne pas pouvoir accéder à la couche de base de données afin de construire / reconstruire le schéma, quand le client de test va-t-il se connecter au serveur: pour chaque test unitaire ou avant l’exécution? la suite de tests?

Answer 1

"Ma question est la suivante: cette approche est-elle correcte?"

C'est ce que vous avez choisi. Vous avez fait beaucoup d'excuses, alors je suppose que vous êtes bien fixé sur ce parcours. Ce n'est pas le meilleur, mais vous avez déjà énuméré toutes vos raisons pour le faire (et vous avez ensuite posé des questions de suivi sur ce plan d'action spécifique). "correct" n'entre plus, il n'y a donc pas de réponse à cette question.

"Quels types de tests sont couverts par cette approche?"

Ils l’appellent "boîte noire". essai. Le serveur d'applications est une boîte noire comportant quelques entrées et sorties et vous ne pouvez tester aucun de ses composants internes. Elle est considérée comme une forme de test acceptable car elle teste le comportement acceptable des interfaces externes.

Si vous avez des problèmes, le travail de diagnostic s'avère inutile. Vous constaterez que vous devez également effectuer des tests en boîte blanche sur les structures internes.

"Il est impossible d'accéder à la couche de base de données pour créer / reconstruire le schéma",

.

Pourquoi pas? Ceci est Python. Ecrivez un outil distinct qui importe cette couche et crée des bases de données.

"Quand le client de test va-t-il se connecter au serveur: à chaque test unitaire ou avant d'exécuter la suite de tests?"

Dépend de l’intention du test. Cela dépend de vos cas d'utilisation. Que se passe-t-il dans le "monde réel"? avec vos clients réels prévus?

Vous souhaitez tester un comportement semblable à celui d'un client, en établissant des connexions de la même manière que les clients.

En outre, vous souhaiterez tester le comportement anormal, par exemple, les clients interrompant des connexions, faisant des choses désordonnées ou non connectés.

Answer 2

Vous devriez utiliser Trial. Ce n'est vraiment pas très difficile. La documentation de la version d'évaluation pourrait être améliorée, mais si vous savez utiliser le test d'unité de bibliothèque standard, la seule différence est qu'au lieu d'écrire

import unittest

vous devriez écrire

from twisted.trial import unittest

... et vous pouvez ensuite renvoyer des différés à partir de vos méthodes test _ . Pratiquement tout le reste est identique.

L’autre différence est qu’au lieu de créer un objet de test géant au bas de votre module, puis d’exécuter

python your/test_module.py

vous pouvez simplement définir vos scénarios de test, puis exécuter

trial your.test_module

Si l'intégration du réacteur ne vous intéresse pas du tout, vous pouvez simplement exécuter trial sur un ensemble de tests unitaires Python existants. La version d'évaluation prend en charge le module de bibliothèque standard unittest '.

Answer 3

Je pense que vous avez choisi la mauvaise direction. C'est vrai que la documentation d'essai est très légère. Mais Trial est basé sur unittest et ajoute seulement quelques éléments pour traiter la boucle du réacteur et les appels asynchrones (il n’est pas facile d’écrire des tests qui traitent des différends). Tous vos tests qui n'incluent pas l'appel deffer / asynchrone seront exactement comme unittest normal.

La commande Trial est un exécuteur de tests (un peu comme avec nose), vous n’avez donc pas à écrire de suites de tests pour vos tests. Vous gagnerez du temps avec cela. De plus, la commande Trial peut générer des informations de profilage et de couverture. Il suffit de faire l'essai -h pour plus d'informations.

Mais de toute façon, la première chose à laquelle vous devriez vous demander, c'est de quel type de tests avez-vous le plus besoin, des tests unitaires, des tests d'intégration ou des tests système (boîte noire). Il est possible de tout faire avec Trial mais ce n’est pas toujours le meilleur choix.

Answer 4

n’a jamais utilisé twisted auparavant, et la documentation twisted / trial n’est pas ce que je viens de voir, mais il vous faudra probablement 2 à 3 jours pour mettre en œuvre correctement le système de test décrit ci-dessus. Maintenant, comme je l'ai dit, je n'ai aucune idée de Trial, mais je suppose que vous pourriez probablement le faire fonctionner dans 1-2 jours, puisque vous avez déjà une application Twisted. Maintenant, si Trial vous donne plus de couverture en moins de temps, j'irais avec Trial.

Mais souvenez-vous que ceci est juste une réponse d'un regard très superficiel sur la documentation