[TIP] unittest issues and development

[holger krekel]

Hi Fernando, 

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'

:)   
Holger


> 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.
> 
> Cheers,
> 
> f
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
> 

--