[TIP] Test Parameterization with unittest

Michael Foord fuzzyman at voidspace.org.uk
Tue May 12 11:18:55 PDT 2009

Doug Philips wrote:
> On or about Tuesday, May 12, 2009, at 07:12AM, Michael Foord indited:
>> I'm also not wild about specifying a dictionary of parameters which then 
>> 'magically' become instance attributes. It would make me antsy writing 
>> tests that use attributes which don't exist until they are stuck onto 
>> the instance.
> Yes, when you put it that way, I agree. Magical attributes <shudder>.
>> I like the *mechanism* of TestWithScenarios though. I'd prefer to 
>> specify a test method and have it called with arguments from the 
>> scenario. I might update my metaclass recipe to do something like this. 
>> Although it isn't suitable for going into unittest.py it is perfectly 
>> usable.
> Hmmm, how is that different (operationally) from funcargs?
> http://codespeak.net/py/trunk/test/funcargs.html
> http://bitbucket.org/hpk42/py-trunk/issue/2/next-generation-generative-tests
I don't really understand how funcargs fits in with generative tests.

My only partial understanding of the funcargs process:

    Define a test function (or several) that takes an argument.

    Pretty much anywhere else define a corresponding function named 
'pytest_funcarg__argumentname' which takes a request object. This is the 

    When tests are run the provider is called with a request object. Any 
return value from this function is then attached to the argument (the 
same request object??) which is passed to the test function?

I don't understand how this allows for generative style tests (multiple 
functions that take the same arguments, multiple providers - neither 
would seem to solve this problem). Nor do I understand how it fits in 
with the pytest_pycollect_genfunction from the second page.

Sorry - obviously quite a lot about it I am not getting. :-)


>> As I don't have a personal need for *either* I think I should avoid 
>> trying to push something into the standard library. It is a subject to 
>> revisit as it seems like a gap in unittest.
> Agreed on all those points, it seems premature to push something just yet.
> -Doug
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python


More information about the testing-in-python mailing list