Initial nose experience

Roy Smith roy at panix.com
Fri Jul 13 14:42:21 CEST 2012


I've been using unittest for many years, but have steadfastly (perhaps 
stubbornly) avoided newfangled improvements like nose.  I finally 
decided to take a serious look at nose.  There were a few pain points I 
had to work through to get our existing collection of tests to run under 
nose.  I figured I'd share them for the benefit of others who may be 
going through the same process.

First nose won't import executable files, at least not by default.

All of our test files are executable, with a "#!/usr/bin/env python" 
line at the top, and a "if __name__ == '__main__'" block, which does 
some setup and invokes unittest.main(), at the bottom.  Going to the top 
of our source tree and typing "nosetests" was an uninspiring experience:

> $ nosetests
> 
> ----------------------------------------------------------------------
> Ran 0 tests in 0.001s
> 
> OK

The fix is either make them non-executable, or do "nosetests --exe".

Next up was the the setup in the "if __name__ == '__main__'" block 
wasn't running.  The solution here is to move all the setup to 
setUpModule(), where it belongs.  SetUpModule() is new in Python 2.7 but 
it turns out it's trivial to drop that version into older systems 
(http://pypi.python.org/pypi/unittest2).

We found a bunch of tests which require some specific setup before they 
could run (most blatantly, some selenium tests which depend on X11).  
When we were running tests semi-manually, that was not a big deal.  With 
nose's "find them all and run them" strategy, this fails.  The obvious 
fix is that every test needs to either set up the right environment, or 
be protected with the appropriate @skip decorator so it doesn't run if 
the environment isn't good.

Lastly, nose, by default, doesn't say much.  When things go wrong and 
you have no clue what's happening, --verbose and --debug are your 
friends.



More information about the Python-list mailing list