Re: [Pyunit-interest] comments on PyUnit

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

Don't look at me to break this tie!  I haven't bee paying enough
attention to be of much help.  Make a proposal.

Some of the forces that go into this:

- Using "assert" sends the wrong message because it suggests an
  equivalence with assert statements, but those are disabled under
  certain compilation options (ditto for the choice to raise
  AssertionError).

- But for some of the functions, noone came up with a reasonable name
  that doesn't use "assert".

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

> Subject: RE: [Pyunit-interest] comments on PyUnit
> From: "Patrick K. O'Brien" <po...@or...>
> To: "Pyunit-Interest" <pyu...@li...>,
>     "Guido van Rossum" <gu...@di...>
> Date: Mon, 2 Jul 2001 15:36:14 -0500
> X-Loop-Detect: 1
> 
> 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