search

nose-devs / nose

nose is nicer testing for python
http://readthedocs.org/docs/nose/en/latest/
1.36k stars 396 forks source link

case sensitive file path comparison in Importer.sameModule() can cause modules to be loaded twice on Windows #118

Open jpellerin opened 12 years ago

jpellerin commented 12 years ago

What steps will reproduce the problem?

  1. create a new virtualenv on Windows. MAKE SURE there is an uppercase letter in the path.
  2. checkout this package: https://bitbucket.org/rsyring/nose-import-bug-example
  3. Activiate venv
  4. python setup.py develop
  5. cd bwimpt
  6. nosetests -s tests/test_import.py

On Linux, you will see something like the following:

id from app 31207560 from test 31207560 id from app 31207560

Ran 0 tests in 0.000s

OK

On Windows, you will see that the app ids are not the same and will get an assertion error.

What version of the product are you using? On what operating system?

Versions: both 0.11.4 and tip as of 11/22/10 OS: Linux & Windows, but the problem only shows up on Windows

Please provide any additional information below.

If you use a fix for issue #293 and use the --first-package-wins option, this bug disappears.

I believe I have tracked the problem down to the code in importer.py that replaces modules. It uses Importer.sameModule() which is using a comparison of file paths that is case sensitive.

My fix is here: https://bitbucket.org/rsyring/blaze-nose/changeset/703767dd9288

FWIW, IMO, this is a pretty significant bug. The result in my application during testing was that 'import foo.bar' would fail with the message that module foo did not have an attribute bar. But we knew the paths were correct b/c the same code worked in production and during testing when using Linux systems. Whats worse was that it just didn't make sense...it took us several days to finally minimalize the test case enough to figure out it was a bug in Nose.

Thanks for your work on this project, I have really gotten into unit & functional testing since I came into contact with nose and have appreciated its flexibility and utility.

Google Code Info: Issue #: 376 Author: rsyr...@gmail.com Created On: 2010-11-23T06:53:03.000Z Closed On:

jpellerin commented 12 years ago

A little more explanation here: http://groups.google.com/group/nose-users/browse_thread/thread/47f1593643754940

Google Code Info: Author: rsyr...@gmail.com Created On: 2010-11-23T18:41:32.000Z

jpellerin commented 12 years ago

Well, it seems my "fix" has broken directory based test discovery...I am looking into that now.

Google Code Info: Author: rsyr...@gmail.com Created On: 2010-11-23T19:56:24.000Z

jpellerin commented 12 years ago

ok, sorry I can't be more help at this point, but I am lost. If you use a fix for issue #293 and use the --first-package-wins option, on windows, directory based discovery of tests stops working. Same if you try the fix I provided, directory based discovery of tests no longer works.

Using --first-package-wins option on linux doesn't seem to break test discovery.

so, this doesn't work:

cd mymodule nosetests

using module based discovery works fine:

nosetests mymodule

Google Code Info: Author: rsyr...@gmail.com Created On: 2010-11-23T21:55:34.000Z

jpellerin commented 12 years ago

Just wondering if I can encourage some movement on this bug. It makes Windows testing annoying when doing things manually, but is now causing some further grief with multi-platform configurations w/ Jenkins.

Thanks.

Google Code Info: Author: rsyr...@gmail.com Created On: 2011-06-17T06:43:50.000Z

jpellerin commented 12 years ago

btw I integrated the fix for Issue 293

As for this one, if you can turn the test suite above into an automated test and submit a patch then it would speed things along. Details are in DEVELOPERS.txt

Google Code Info: Author: kumar.mcmillan Created On: 2011-06-17T19:45:30.000Z