RetroSearch Browse

Wed Jan 11 20:59:00 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-January/059658.html

[Stephen J. Turnbull wrote]
> >>>>> "Fredrik" == Fredrik Lundh <fredrik at pythonware.com> writes:
> 
>     Fredrik> many test frameworks support "expected failures" for this
>     Fredrik> purpose.  how hard would it be to add a
> 
>     Fredrik>     unittest.FailingTestCase
> 
>     Fredrik> class that runs a TestCase, catches any errors in it, and
>     Fredrik> signals an error ("test foo passed unexpectedly") if it
>     Fredrik> runs cleanly ?
> 
> One can do even better than that.  unittest.FailingTestCase should
> (except possibly for platform dependencies) know _how_ the TestCase is
> expected to fail.  You also want to know if the error changes.

How about this:

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307970
    a better assertRaises() for unittest.py 

    When writing unit tests for Python using the standard unittest.py
    system the assertRaises() (aka failUnlessRaises()) method is used to
    test that a particular call raises the given exception. This recipe
    if for assertRaisesEx() that adds three things: (1) the ability to
    assert the raised exception's args; (2) the ability to test that the
    stringified exception matches a given regular expression; and (3)
    much better failure messages.

I haven't read this thread, so apologies is this doesn't really apply to
the discussion.

Cheers,
Trent

-- 
Trent Mick
trentm at activestate.com

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-January/059658.html below:

[Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940