[TIP] new test parametrization / deprecating "yield"

Douglas Philips dgou at mac.com
Thu May 14 22:57:47 PDT 2009

On or about 2009 May 14, at 8:08 AM, holger krekel indited:
> On Wed, May 13, 2009 at 15:27 -0400, Doug Philips wrote:
>> I am not clear from that post and the py.test funcargs page
>> it links to, just where/how many pytest_generate_tests
>> functions there can be and when in the test-running-timeline
>> they/it are run.
> I see.  I've written up a new blog post which hopefully clarifies
> this and explains how the generate-tests hook can live
> in a "local" or "global" plugin:
>    http://tetamap.wordpress.com/2009/05/14/putting-test-hooks

Thanks. I'm still not clear on when the funcarg providers are called.
Are they called as the modules are being loaded? (that doesn't seem  
Are they called "just in time" as the test method itself is about to  
be called?


This section also caught my eye:
multiple pytest_generate_hook implementations
So, you say, what about a test function with multiple arguments –  
could each function argument come from a different generating provider?

This would mean that multiple generators act independently but want to  
collaborate and combine their values for a given test functions. Well,  
if you encounter a real need for it, please come forward and we’ll  
think up a fitting API extension. A couple of days ago i had a  
"combining funcargs" API call implemented but decided to remove it  
because i try hard these days to only add features that have a proven  

I had thought combining values would be a natural extension.
For example, one of the things that -some- of our device tests needs  
is a power controller.
But not all test code needs it.
Right now our common TestCase base class arranges for setUp to stash  
the power controller onto 'self' (during setUp). So that any test  
which wants a power controller will have it. IMHO it would be a lot  
cleaner if the test method simply declared it funcargs style:

def test_rapid_fire_power_cycling(self, power_controller, ...):
     while <...>:

the power_controller func_arg being an independent entity for other  
funcarg supplied parameters.

But again I'm not doing unit testing, I'm just using the unittest  
framework to do device testing. :)


More information about the testing-in-python mailing list