[TIP] Functions for tests instead of classes

[Mark Roddy]

On Mon, Mar 15, 2010 at 2:42 PM, Pekka Klärck <peke at iki.fi> wrote:
> 2010/3/15 Michael Foord <fuzzyman at voidspace.org.uk>:
>> On 15/03/2010 17:46, Pekka Klärck wrote:
>>>
>>> [snip...]
>>>>
>>>> Then, to retain compatibility with older versions of unittest, the
>>>> TestCase
>>>> object can contain a bunch of trivial methods like:
>>>>
>>>>   def assertEqual(self, a, b) :
>>>>      return assertEqual(a,b)
>>>>
>>>
>>> Yep, keeping backwards compatibility would be trivial. Are there any
>>> good reasons not to do this?
>>>
>>
>> Per TestCase failureException is one reason.
>
> How, and how often, is this functionality actually used? Would you be
> OK with the change if there was a way to keep it? Or could we simple
> have asserts in a separate module and not touch TestCase at all?
>
> Cheers,
>    .peke
> --
> Agile Tester/Developer/Consultant :: http://eliga.fi
> Lead Developer of Robot Framework :: http://robotframework.org
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>

Doing a google code search, it seems that this would affect not use
just unittest, but a decent number of smallish extensions:
http://www.google.com/codesearch?hl=en&lr=&q=lang%3Apython+%5C.failureException&sbtn=Search

(one of) The easiest way to add your own assertions is to subclass
TestCase and add your new assertions on there, and raise
self.failureException when the expected condition was not met (as seen
in the majority of these search results).  Removing the
failureException attribute would break backwards compatibility with
everyone who has done this.  This appears to include zope, twisted,
and cherrypy from the above search results, though further inspection
may reveal these to no longer be issues for these specific projects.

-1 on removing failureException due to breaking backwards compatibility