[TIP] Functions for tests instead of classes
fuzzyman at voidspace.org.uk
Mon Mar 15 12:20:51 PDT 2010
On 15/03/2010 18:21, Mark Sienkiewicz wrote:
> Michael Foord wrote:
>> On 15/03/2010 17:46, Pekka Klärck wrote:
>>>> Then, to retain compatibility with older versions of unittest, the
>>>> 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.
> I don't understand what you mean. (Or maybe, I do understand, but I
> don't see how it is a problem.)
> You could have a module full of friendly assert functions, but if you
> need a custom assert function for your object, you can still have
> one. After all, if your test contains a special assertEqual, you are
> going to have to override the assertEqual in the base class -- i.e.
> you write your own anyway.
What I mean is that the methods already access class (or instance) state
- so you would need extra parameters to your assert functions or have to
forgo that functionality.
In terms of a programmers API I don't really see any win though. Either
you import *all* the assert functions, or you import the module and use
'module.assert_equal'. You're not going to advocate "import *" surely? :-)
> Mark S.
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