Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Initial nose experience
84 views
Skip to first unread message
Roy Smith
Jul 13, 2012, 8:42:21 AM7/13/12
to
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.
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.
pyt...@bdurham.com
Jul 15, 2012, 2:02:29 PM7/15/12
to Roy Smith, pytho...@python.org
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
> 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.
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
Roy Smith
Jul 15, 2012, 2:58:22 PM7/15/12
to
In article <mailman.2149.1342375...@python.org>,
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.
pyt...@bdurham.com 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.
> 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?
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.
Philipp Hagemeister
Jul 16, 2012, 6:54:06 AM7/16/12
to Roy Smith, pytho...@python.org
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
>> 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.
break anything to look in . , ./test, ./tests for any files matching
test_* , and execute those?
- Philipp
Roy Smith
Jul 16, 2012, 7:33:38 AM7/16/12
to
> 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
> cons of nose?
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.
Peter Otten
Jul 16, 2012, 7:47:19 AM7/16/12
to pytho...@python.org
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
> 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 Hagemeister
Jul 16, 2012, 8:37:33 AM7/16/12
to Peter Otten, pytho...@python.org
On 07/16/2012 01:47 PM, Peter Otten wrote:
> http://docs.python.org/library/unittest#test-discovery
That's precisely it. Can we improve the discoverability of the discover
option, for example by making it the default action, or including a
message "use discover to find test files automatically" if there are no
arguments?
- Philipp
> http://docs.python.org/library/unittest#test-discovery
That's precisely it. Can we improve the discoverability of the discover
option, for example by making it the default action, or including a
message "use discover to find test files automatically" if there are no
arguments?
- Philipp
Ben Finney
Jul 16, 2012, 8:37:58 AM7/16/12
to
Roy Smith <r...@panix.com> writes:
> In article <mailman.2149.1342375...@python.org>,
> pyt...@bdurham.com 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
> In article <mailman.2149.1342375...@python.org>,
> pyt...@bdurham.com 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
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
Ben Finney
Jul 16, 2012, 8:45:41 AM7/16/12
to
Philipp Hagemeister <phi...@phihag.de> writes:
> On 07/16/2012 01:47 PM, Peter Otten wrote:
> > http://docs.python.org/library/unittest#test-discovery
>
> That's precisely it. Can we improve the discoverability of the discover
> option
Having it prominently in the documentation for the ‘unittest’ module is
> On 07/16/2012 01:47 PM, Peter Otten wrote:
> > http://docs.python.org/library/unittest#test-discovery
>
> That's precisely it. Can we improve the discoverability of the discover
> option
already pretty discoverable, IMO.
> for example by making it the default action, or including a message
> "use discover to find test files automatically" if there are no
> arguments?
submit a bug report requesting it, if you think it's needed
<URL:http://bugs.python.org/>.
--
\ “Do not enter the lift backwards, and only when lit up.” |
`\ —elevator, Leipzig |
_o__) |
Ben Finney
Philipp Hagemeister
Jul 16, 2012, 8:49:08 AM7/16/12
to Peter Otten, pytho...@python.org
On 07/16/2012 02:37 PM, Philipp Hagemeister wrote:
> Can we improve the discoverability of the discover
> option, for example by making it the default action, or including a
> Can we improve the discoverability of the discover
> message "use discover to find test files automatically" if there are no
> arguments?
Oops, already implemented as of Python 3.2. Sorry, should've checked before.
> arguments?
- Philipp
Roy Smith
Jul 23, 2012, 1:33:34 PM7/23/12
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?
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?
Roy Smith
Jul 27, 2012, 10:51:48 AM7/27/12
to
In article <roy-F2685A.0...@news.panix.com>,
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.
Roy Smith <r...@panix.com> 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
> 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.
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.
0 new messages