Re: [Pyunit-interest] comments on PyUnit

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

> Steve wrote:
> > > I think this can be safely done in time for this week's 2.1 release
> > > (though that's not *my* call to make).
> 
> Guido replied:
> > The code freeze is planned to start Thursday (probably Thu afternoon),
> > so you have approximately a day!
> 
> 
> I have now checked the changes into both the Python and PyUnit CVS trees.
> 
> The complete set of fail*() methods, together with their 'assert*' synonyms,
> is now:
> 
>    fail()
>    failIf()
>    failUnless()           --   assert_()
>    failIfEqual()          --   assertNotEqual(), assertNotEquals()
>    failUnlessEqual()      --   assertEqual(), assertEquals()
> 
> There is a new attribute 'failureException' in the TestCase class; this
> attribute parameterises the exception that indicates test failures, and
> is set to 'AssertionError' by default. Subclasses may override it if they
> wish:
> 
>     class TestFailed(Exception): pass
> 
>     class StandardTestCase(unittest.TestCase):
>        failureException = TestFailed
> 
> or even:
> 
>     class StandardTestCase(unittest.TestCase):
>        class failureException(Exception): pass
> 
> I will make a new PyUnit release at the weekend that will correspond to the
> 'unittest.py' included in the Python 2.1 final release.
> 
> Best wishes,

Thanks, Steve!

> > Then all methods should get new names, right?  It's a shame we can't
> > use check (or can we?), otherwise that would be my preference.  What
> > does JUnit use?
> 
> JUnit uses assert and assertEquals, which is a vote in favour or those names.
> 
> Why don't we just bite the bullet and document the synonyms? Obviously
> tastes differ significantly in this area.

OK, that makes the most sense given our deadline.  Sometimes, there's
more than one way to do it! :-)

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