2010-09-30 22 views
0

Je passe de notre environnement de test de Nose à py.test pour tester une application web Turbogears2. Actuellement, lorsque Nose s'exécute, il rassemble les informations d'un fichier de configuration de test (test.ini) contenant toutes les variables de test dont l'application a besoin. Et il semble le faire de manière automatique (Je cours simplement nosetests et tout est chargé)Turbogears2 et py.test

Le problème réside dans l'incapacité de py.test à pointer sur le bon fichier de configuration INI afin que je puisse obtenir l'application chargée avec les variables dont j'ai besoin.

Actuellement, le point de défaillance est pylons.app_globals, qui est simplement inexistant lors de l'exécution de py.test (tout échoue donc).

J'ai parcouru la documentation de Turbogears mais ils ne mentionnent que le nez/nosetests et rien d'autre.

Existe-t-il un moyen de diriger l'application avec les variables de test sur lesquelles je me base avec py.test?

Répondre

1

En ce qui concerne la part de py.test est concerné, vous pouvez mettre en œuvre quelque chose comme ceci:

# content of conftest.py 
def pytest_sessionstart(): 
    # setup resources before any test is executed 

def pytest_sessionfinish(): 
    # teardown resources after the last test has executed 

Un tel fichier conftest.py devrait actuellement le mieux vivre à votre caisse répertoire racine comme py-1.3.4 sera ne lancez ce crochet que s'il le voit assez tôt. J'ai aussi regardé un peu TurboGears mais je n'ai pas trouvé le mécanisme comment/qui test.ini est réellement chargé. Je peux mettre à jour la réponse si quelqu'un peut fournir cette information.

HTH. Holger

+0

wow, merci Holger! c'est vraiment une leçon d'humilité d'avoir une réponse de votre part! tu gères! Quant au problème lui-même, la façon dont le nez rassemblait les valeurs de l'application via la méthode setUp. – alfredodeza

+0

votre bienvenue, Alfredo. Avez-vous une URL pointant vers le code qui implémente cette fonctionnalité setUp et peut-être contient des exemples de tests? – hpk42

+0

Malheureusement, ce n'est pas un projet OSS. Cependant, j'ai une meilleure idée de ce qui s'est passé. Fondamentalement, nous étions en train d'implémenter une classe TestSetupCommand qui mettrait tout à jour, donc je porte ce portage pour correspondre aux exigences de py.test. – alfredodeza