Mailing List Archive: Python: Python

Initial nose experience

Index | Next | Previous | View Threaded

roy at panix

Jul 13, 2012, 5:42 AM

Post #1 of 9 (388 views)
Permalink

Initial nose experience

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.
--
http://mail.python.org/mailman/listinfo/python-list

python at bdurham

Jul 15, 2012, 11:02 AM

Post #2 of 9 (360 views)
Permalink

Re: Initial nose experience [In reply to]

Hi Roy,

> 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.

Thanks for sharing your nose experience.

What motivated you to migrate from unittest to nose?

After years of using unittest, what would you say are the pros and
cons of nose?

Thank you,
Malcolm
--
http://mail.python.org/mailman/listinfo/python-list

roy at panix

Jul 15, 2012, 11:58 AM

Post #3 of 9 (359 views)
Permalink

Re: Initial nose experience [In reply to]

In article <mailman.2149.1342375358.4697.python-list [at] python>,
python [at] bdurham wrote:

> Hi Roy,
>
> > 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.
>
> Thanks for sharing your nose experience.
>
> What motivated you to migrate from unittest to nose?

Mostly I was just looking for a better way to run our existing tests.
We've got a bunch of tests written in standard unittest, but no good way
to start at the top of the tree and run them all with a single command.
--
http://mail.python.org/mailman/listinfo/python-list

phihag at phihag

Jul 16, 2012, 3:54 AM

Post #4 of 9 (359 views)
Permalink

Re: Initial nose experience [In reply to]

On 07/15/2012 08:58 PM, Roy Smith wrote:
>> What motivated you to migrate from unittest to nose?
> Mostly I was just looking for a better way to run our existing tests.
> We've got a bunch of tests written in standard unittest, but no good way
> to start at the top of the tree and run them all with a single command.

Currently, $ python -m unittest does nothing useful (afaik). Would it
break anything to look in . , ./test, ./tests for any files matching
test_* , and execute those?

- Philipp

Attachments:

signature.asc (0.19 KB)

roy at panix

Jul 16, 2012, 4:33 AM

Post #5 of 9 (359 views)
Permalink

Re: Initial nose experience [In reply to]

In article <mailman.2149.1342375358.4697.python-list [at] python>,
python [at] bdurham wrote:

> After years of using unittest, what would you say are the pros and
> cons of nose?

BTW, although I'm currently using nose just as a unittest aggregator, I
can see some nice advantages to native nose functionality. The most
obvious is that tests can be plain-old static functions at the top level
of a module.

In unittest, you have to subclass TestCase, then write methods for that
(showing its JUnit/SUnit roots). In 99% of the tests I write, I don't
do anything special in my TestCase subclasses, so that's all just
boilerplate busywork. I like the idea that I can skip that all now.
--
http://mail.python.org/mailman/listinfo/python-list

__peter__ at web

Jul 16, 2012, 4:47 AM

Post #6 of 9 (363 views)
Permalink

Re: Initial nose experience [In reply to]

Philipp Hagemeister wrote:

> Currently, $ python -m unittest does nothing useful (afaik). Would it
> break anything to look in . , ./test, ./tests for any files matching
> test_* , and execute those?

http://docs.python.org/library/unittest#test-discovery

--
http://mail.python.org/mailman/listinfo/python-list

ben+python at benfinney

Jul 16, 2012, 5:37 AM

Post #7 of 9 (361 views)
Permalink

Re: Initial nose experience [In reply to]

Roy Smith <roy [at] panix> writes:

> In article <mailman.2149.1342375358.4697.python-list [at] python>,
> python [at] bdurham wrote:
>
> > After years of using unittest, what would you say are the pros and
> > cons of nose?
>
> BTW, although I'm currently using nose just as a unittest aggregator

Be aware that Python 2.7 and higher has unit test discovery in the
standard library:

$ python -m unittest discover

will look through all packages within the current directory and collect
unit tests it finds, then run them and report
<URL:http://docs.python.org/library/unittest.html#test-discovery>.

You can get the same in earlier versions of Python with ‘unittest2’
<URL:http://pypi.python.org/pypi/unittest2>.

--
\ “I prayed for twenty years but received no answer until I |
`\ prayed with my legs.” —Frederick Douglass, escaped slave |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

roy at panix

Jul 23, 2012, 10:33 AM

Post #8 of 9 (342 views)
Permalink

Re: Initial nose experience [In reply to]

Does nose run all of its collected tests in a single process?

I've got a test which monkey-patches an imported module. Will all of the other tests collected in the same run of nosetests see the patch?
--
http://mail.python.org/mailman/listinfo/python-list

roy at panix

Jul 27, 2012, 7:51 AM

Post #9 of 9 (337 views)
Permalink

Re: Initial nose experience [In reply to]

In article <roy-F2685A.08422113072012 [at] news>,
Roy Smith <roy [at] panix> wrote:

> 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.

I found another example of nose not saying much, and this one is kind of
annoying. Unittest has much richer assertions, and better reporting
when they fail. If a nose assertion fails, you just get:

------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/roy/production/python/lib/python2.6/site-packages/nose/case.py",
line 197, in runTest
self.test(*self.arg)
File "/home/roy/songza/pyza/djapi/test_middleware.py", line 48, in
test_update_non_json_cookie
assert user_list == [9990]
AssertionError
------------------------------------------------------------------

Under unittest, it would have printed the value of user_list. Yeah, I
know, I can stick a "print user_list" statement into the test, and the
output will get suppressed if the test fails. But that means when a
test fails, I need to go back and edit the test code, which is a pain.

On the other hand, there *is* an incremental efficiency gain of writing:

assert x == y

instead of

assertEqual(x, y)

many times. So maybe overall it's a wash.
--
http://mail.python.org/mailman/listinfo/python-list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads