[TIP] Functions for tests instead of classes

Michael Foord fuzzyman at voidspace.org.uk
Mon Mar 15 12:22:00 PDT 2010


On 15/03/2010 18:42, Pekka Klärck 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?

It is part of the current API, so it doesn't particularly matter how 
much it is used - to change it would be a backwards incompatibility and 
have to go through the deprecation cycle.

To use it:

class TestFoo(TestCase):
failureException = MyException

self.fail() in tests now raise MyException instead of the default 
failureException which is AssertionError. Tests will now only be marked 
as a fail (rather than an error) if MyException is raised.

Also note that the class attribute longMessage is used for formatting 
failure messages - so to remain fully compatible custom assert functions 
would need access to these attributes (and any others that may be 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?
>
>    

You can have asserts whereever you want them. Just define them and use 
them :-)

unittest is a framework - there is absolutely *no* requirement to use 
the facilities it provides.

Michael

> Cheers,
>      .peke
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.





More information about the testing-in-python mailing list