Re: [Pyunit-interest] comments on PyUnit

[Guido v. R. <gu...@di...>]

> Fred L. Drake, Jr. wrote:
> >   I notice that it still isn't calling TestCase.fail() in all the
> > fail<Something>() methods -- were we still agreed on that?  I can make
> > that change is needed.
> 
Steve:
> I decided against that; the extra level of traceback output is unsightly.

Agreed.

> The failure exception is now parameterised, and the framework is not written
> such that it would be safe and/or desirable to override fail() in subclasses.

OK, fine.

> >   Since Guido's suggested we document both naming famillies, we should
> > have a second name for this -- I suggest "assertNot()".
> 
> I also decided against this; fail() does not have a common-sense
> 'assert' counterpart, and 'assertNot' is better served by 'assert_(not expr)'
> for those users who prefer 'assert*' to 'fail*'.

Agreed.

> A bit of relevant background: JUnit lives quite happily with the following:
> 
>     fail()
>     assert(expr)
>     assertEquals(a,b)
>     assertSame(a,b)

But Java doesn't have an assert statement in the language!

> If I were starting PyUnit from scratch, I would provide only:
> 
>     fail()
>     assert_(expr)

This is an ugly name, though (and that's what started this debate).

>     assertEquals(a,b)

Why even bother with this?  I'd say assert_(a == b) is good enough.

>     assertRaises(exception,func,*args,**kwargs)

This is a useful utility.

But, the problems I pointed out with assert will remain as long as we
have names starting with assert...  :-(

--Guido van Rossum (home page: http://www.python.org/~guido/)