RE: [Pyunit-interest] comments on PyUnit

[Patrick K. O'B. <po...@or...>]

With the benefit of some couple of months behind us, and with the inclusion
of unittest in the standard Python distro, will there be any consensus on
which version of these method names to use? Will there be one Python way, or
are we doomed to an unusual amount of variety? I'm asking from the point of
view of someone who doesn't have a lot of legacy pyUnit code. I see an
opportunity for Python to introduce good coding habits, which is why I'm
sure you all pushed for unittest as part of the standard library.

Unfortunately, one is left with a rather schizophrenic implementation in a
couple of ways. First, the documentation
(http://www.python.org/doc/current/lib/testcase-objects.html) lists both
method names without any indication as to why there are two and which is to
be preferred. One could assume that the assert* is better as it is listed
first. But it might also simply be in alphabetical order. Then one looks at
the code as sees the methods defined with the fail* name and the following
synonyms:

    assertEqual = assertEquals = failUnlessEqual

    assertNotEqual = assertNotEquals = failIfEqual

    assertRaises = failUnlessRaises

    assert_ = failUnless

This would seem to imply that the fail versions are to be preferred. Of
course, the other language testing frameworks use the assert versions, as
does Mark Pilgrim's excellent tutorial. Looking at the unit tests that test
Python itself we can even find "verify." This is all too confusing to
someone as anal retentive as I am. So I am asking for a word from on high.
If one were starting from square one and wanted to write unit tests the
Python way, what way would that be?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Guido van
Rossum
Sent: Thursday, April 12, 2001 1:54 PM
To: Steve Purcell
Cc: Fred L. Drake, Jr.; pyu...@li...
Subject: Re: [Pyunit-interest] comments on PyUnit

> 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/)

_______________________________________________
Pyunit-interest mailing list
Pyu...@li...
http://lists.sourceforge.net/lists/listinfo/pyunit-interest