[TIP] unittest issues and development

[Fernando Perez]

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.

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