10
votes

Comment organiser et exécuter des pressions et des tests fonctionnels séparément à l'aide de nosetests

J'ai la structure de fichier de projet Python typique suivante

packageA
   +----subpackage1
            +----classa.py
   +----subpackage2
            +----classb.py
   +----test
          +----subpackage1
                    +----classa_test.py 
          +----subpackage2
                    +----classb_test.py

Qu'est-ce qu'un bon moyen d'organiser les différents tests? Par dossier (fonctionnel / vs unité /)? En nommant la Convention de la classe d'essais (ClassAtest VS CLASSOCONCELTEST)? ou en nommant la convention des méthodes de test (ClassA_FOO_TEST VS CLASSA_BAR_FCUNTIONAL_TEST)? LI>
Quelqu'un peut-il expliquer comment fonctionne la correspondance de regex de NoseTest? Les options -M, -I et -E ne semblent pas courir comme je m'attends à courir. Est-ce que les répertoires de correspondance REGEX (SUBPACACAGE1), les fichiers (CLASSA_TEST) ou les classes de test (CLASSATEST) ou les méthodes de test (CLASSA_FOO_TEST)? Je suis extrêmement confus li> ul> p>

python unit-testing nose functional-testing nosetests

0 commentaires

3 Réponses :

-2
votes

J'essaierais d'organiser le test par zone fonctionnelle. Je ne sais pas vraiment quel nez est.

Mais si vous testez par exemple une zone de connexion pour une page Web, créez un sous-dossier appelé «Connexion» ou «LoginTrests», et pour le test de menu Créez un dossier «Menuest» ou «MenuTest». Il est toujours bon d'avoir de bonnes conventions de nommage également, alors nommez le test et les dossiers exactement ce qu'ils testent. Être aussi précis que possible.

0 commentaires

8
votes

Ma structure de répertoire de tests a l'air de cette façon:

root
  + --- tests
  |       + --- unit_tests
  |       |         + --- some_app_tests   
  |       |         + --- another_app_tests
  |       |         | run_tests.py
  |       |
  |       + --- integrate_tests 
  |                 + --- some_app_tests
  |                 + --- another_app_tests
  |                 | run_tests.py
  |       
  + --- project_root
          + --- some_app
          + --- another_app

2 commentaires

Vous dites "Chaque répertoire est un projet Django séparé avec des paramètres personnalisés et une commande de gestion utilisée pour exécuter des tests" mais votre arbre ne le montre pas. En outre, quelle est la commande de gestion personnalisée que vous utilisez?

@supervacuo je n'ai pas dit Commande de gestion personnalisée , mais commande de gestion avec Paramètres personnalisés . Les tests sont exécutés par Django-Sane-Test via la commande Manage.py Test (avec quelques modifications dans les paramètres, enveloppés dans run_tests.py , voir DST DOC - Django-sane-testing.Readthedocs.org/fr/Latest/... < / a>)

1 votes Si vous développez Django Project, vous pouvez essayer cette bibliothèque: onclebob https://github.com/gabrielfalcao/gabrifalcao/ Onclebob Cela suggère comment organiser et exécuter vos tests de l'unité et vos tests fonctionnels. 1 commentaires +1 Je n'avais pas vu onclebob avant, mais il semble un moyen très agréable d'encourager de bonnes pratiques de test (j'aime particulièrement comme "si vous n'exécutant que les tests de l'unité, alors cegobob ne va pas configurer le Testez la base de données »), et elle est même assez récemment mise à jour.

Articles qui pourrait vous intéresser : Python: ConnectionError: HTTPSConnectionPool (hôte = 'api.foursquare-com', port = 443) L'exécution de Flask sous Windows n'exécute pas la commande d'exécution de flask Chatbot installé mais obtention d'une erreur lors de l'importation de ChatBot Administrateur Django: __str__ a renvoyé une non-chaîne (type int)