ImportError utilisant le nez, pas d'importError utilisant unittest brut?

Question

Je reçois un ImportError lors de l'exécution de mes unittets en utilisant Nose et je ne le fais pas lorsque je l'exécute seul. Tous les fichiers mentionnés ici peuvent être vus au http://gist.github.com/395541#.

Si je lance le script de test, importTest-Test.py, directement cette sortie je reçois:

C:\usr\x\data\src\Python\mmm>python importTest-Test.py 
In mmdb 
In BusinessLogic 
[] 
. 
---------------------------------------------------------------------- 
Ran 1 test in 0.001s 

Si je laisse Nose pour l'exécuter je reçois une erreur:

C:\usr\x\data\src\Python\mmm>nosetests.exe 
E 
====================================================================== 
ERROR: Failure: ImportError (No module named mmdb.DataAccess.AttemptDB) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
    File "c:\bin\installed\python2.6\lib\site-packages\nose-0.11.3-py2.6.egg\nose\loader.py", line 382, in loadTestsFromName 
    addr.filename, addr.module) 
    File "c:\bin\installed\python2.6\lib\site-packages\nose-0.11.3-py2.6.egg\nose\importer.py", line 39, in importFromPath 
    return self.importFromDir(dir_path, fqname) 
    File "c:\bin\installed\python2.6\lib\site-packages\nose-0.11.3-py2.6.egg\nose\importer.py", line 86, in importFromDir 
    mod = load_module(part_fqname, fh, filename, desc) 
    File "C:\usr\x\data\src\Python\mmm\importtest-Test.py", line 2, in <module> 
    import importtest 
    File "C:\usr\x\data\src\Python\mmm\importtest.py", line 1, in <module> 
    from mmdb.BusinessLogic.AttemptManager import AttemptManager 
    File "C:\usr\x\data\src\Python\mmm\mmdb\BusinessLogic\AttemptManager.py", line 1, in <module> 
    from mmdb.DataAccess.AttemptDB import AttemptDB 
ImportError: No module named mmdb.DataAccess.AttemptDB 

---------------------------------------------------------------------- 
Ran 1 test in 0.002s 

FAILED (errors=1) 

Les fichiers impliqués dans le paquet avec lequel le nez a des difficultés sont dans la structure suivante - certains peuvent être vus ici http://gist.github.com/395541#:

mmm\importtest-Test.py 
mmm\importtest.py 
mmm\mmdb 
mmm\__init__.py 
mmm\mmdb\BusinessLogic 
mmm\mmdb\BusinessObject 
mmm\mmdb\DataAccess 
mmm\mmdb\__init__.py 
mmm\mmdb\BusinessLogic\AttemptManager.py 
mmm\mmdb\BusinessLogic\Collections 
mmm\mmdb\BusinessLogic\__init__.py 
mmm\mmdb\BusinessLogic\Collections\__init__.py 
mmm\mmdb\BusinessObject\__init__.py 
mmm\mmdb\DataAccess\AttemptDB.py 
mmm\mmdb\DataAccess\__init__.py 

Cela se produit sous Win32/Python 2.6/Nose 0.11.3.

Je serais reconnaissant pour toute aide.

merci.

Answer 1

Par défaut, le nez manipule le PYTHONPATH qu'il utilise. Vous pouvez essayer de désactiver ce comportement en utilisant l'option -P.

Answer 2

Vous pouvez essayer de supprimer __init__.py du dossier de niveau supérieur mmm (réponse originale ici: https://stackoverflow.com/a/3073368/19166)

Answer 3

On dirait que votre problème pourrait être dû au tableau de bord « - » dans votre nom de fichier. Voir aussi: https://stackoverflow.com/a/11055442/1063605

Answer 4

Ceci est une réponse pour un cas d'utilisation très spécifique impliquant PyUnit.

J'avais un ensemble de tests unitaires fonctionnant correctement sous PyDev. Un jour, j'ai fait une faute de frappe, et PyDev a ajouté une importation automatique pour une partie du paquet pandas. Je garde habituellement mon code plié, donc je ne l'ai pas vu tout de suite.

L'erreur apparue dans une partie ultérieure de l'ensemble de test était "Erreur: impossible d'importer le nez".

Lors du débogage, j'ai trouvé qu'un nom de fichier de données avait un des noms de sous-répertoire répétés. Il est apparu que le coureur de test changeait le répertoire de travail en le sous-répertoire contenant le fichier .py, mais ne revenait pas au répertoire du projet. Un appel à os.path.realpath ("_ fichier _") pour configurer le chemin du fichier de données renvoyait le sous-répertoire de test au lieu du répertoire de projet attendu, avec l'effet net que les données n'étaient pas trouvées et que le test échouait. "Corriger" le code qui a mis en place le chemin de fichier de données a résolu cette erreur

Cependant, pendant que je retravaillais les erreurs restantes, j'ai découvert et enlevé l'instruction importée non désirée. À ce stade, le chemin d'accès au fichier de données a commencé à générer des erreurs. Je l'ai donc redéfini sur le formulaire d'origine et tout s'est bien passé. Donc, si vous constatez que vous avez soudainement ces erreurs de "nez", il est possible que votre édition ait introduit par inadvertance une instruction d'importation qui détraque PyUnit.J'ajoute la réponse ici parce qu'une partie de mon expérience consistait à exécuter les fichiers de test individuels avec unittest brut (à partir du menu contextuel de PyDev), et se sentant très perplexe quant à la raison pour laquelle ils ont travaillé de cette façon mais pas quand ils coureur d'essai complet.