[TIP] unittest issues and development
holger at merlinux.eu
Wed Feb 10 17:29:50 PST 2010
On Wed, Feb 10, 2010 at 19:20 -0500, Fernando Perez wrote:
> On Wed, Feb 10, 2010 at 6:32 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
> > Unfortunately there are a lot of names and we just got rid of a lot of
> > duplicates. It was discussed previously, but the conclusion was that we
> > couldn't introduce a new set of duplicate names (effectively doubling what
> > is already a fairly large API).
> Ok, fair enough.
> >> as well as top-level names for the various
> >> assertions? Nose.tools does that in a very simple but useful manner
> >> that makes lightweight (non-class-based) tests really nice to write:
> >> def test_foo():
> >> nose.tools.assert_equals(bar, baz, 'nice message)
> > I've never seen the advantage of this over self.assertEquals (ignoring the
> > PEP 8 issue...). :-)
> Ah, they matter if you aren't writing a class: there is no 'self' in
> the function above. One very nice thing about such tests in the
> contexts I work in (scientists who don't necessarily care or want to
> know about objects) is that the above is a valid test that states
> precisely the desired goal with pretty much zero boilerplate.
Nah, zero boilerplate (tm) is this:
assert bar == baz, 'nice message'
> If I have to tell scientists that before writing a test they have to
> subclass some special contraption from unittest, and know about self,
> etc, I'd have to postpone testing until classes have been somewhat
> introduced. But the above approach lets me put tests in pretty much
> from day 1, which is good.
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
More information about the testing-in-python