[TIP] Functions for tests instead of classes

[Michael Foord]

On 17/03/2010 16:54, Mark Sienkiewicz wrote:
> Michael Foord wrote:
>> On 15/03/2010 18:21, Mark Sienkiewicz wrote:
>>> 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.
>
> It never occurred to me that anybody would do that.  Seriously, if you 
> are comparing whether two things are equal, what _possible_ data could 
> you need access to other than those two things?
> Well, the answer appears to be "other stuff that is defined in the 
> test case object".  I would not design it that way, but I can see how 
> you are constrained by backward compatibility.
>

Yeah, I mean who would imagine that instance methods would use instance 
attributes? ;-)

>
>> 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? :-)
>
> If you also advocate against "import *", I then there will be at least 
> two of us. :)
>
> I generally value readability over speed, so I would use 
> module.assert_equal(a,b).  Or, if I might call the module "assertions" 
> and the function "equal" so you can write "assertions.equal(a,b)"
>
> Using the "special object" that you mentioned some time ago, that 
> could be
>
> from unittest2 import assertions
> # assertions is a TestCase object that contains no tests, but it is 
> not in this namespace
> # so no test runners will detect it when we run the tests in this file
>
> def test() :
>    ...
>    assertions.assertEqual(a,b)
>

I fail to see any advantage (beyond extra typing) over 
self.assertEqual(a, b).

Michael


>
> Mark S.


-- 
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.