[TIP] Meta-test methods...

Douglas Philips dgou at mac.com
Thu Apr 23 06:06:42 PDT 2009

On or about 2009 Apr 23, at 1:14 AM, C. Titus Brown indited:
> Anyway, I double-dare you to make this:
> 	http://github.com/ctb/figleaf/blob/d11d2ee0ce70427b229af15409bff2ab23e090d2/tests/test_regress/__init__.py
> work nicely without decorators.

??? With decorators, you mean?

> -> I'm now convinced that explicit use of decorators is the right  
> way to
> -> go.
> ...says the man not supporting python2.3 ;)

Nose doesn't support it either. The hackery for detecting generators  
imports symbolic constants from the compiler which don't exist until >  
2.4 (the version I use). I tracked it down after PyCon, but no longer  
recall if you need 2.5 or 2.6 for that to be defined. It "works"  
because the import failure has a fall back to defining the same  
constant value, the comment there is misleading since it is not just  
IronPython, but older versions of CPython don't define that constant  

> -> Maybe, just maybe, a naming convention that would parallel the
> -> unittest notion of all methods starting with the name 'test'  
> would be
> -> acceptable.
> I musta missed something.  That's exactly what nose (and py.test) do.

No, they don't. Take a look at:
Both that code and the code in py.test access func.func_code.co_flags  
and check for generator-ness.

Using the 'is a generator' test is a hack, and utterly fails to  
generalize to a mechanism that permits the general Pythonic notion of  
sequence to be used instead. As I said earlier in this thread, at  
first I swooned and thought that was cool. But upon further reflection  
I came to my senses and realized it was just a hack.

You said that 2.3 not being compatible with decorators was an issue. I  
have two responses to that:
     def <my meta test method....>
     <my meta test method....>.is_meta_method = True
is not as ugly as you might think, and it is explicit.

However, I understand the beauty/simplicity/etc. of decorators and  
will concede that the lack of them could be an issue.
An alternative (and I haven't had time to consider if it is better or  
just different) is to use a naming convention the way current test  
discovery is done. ("Names are hard" and I don't claim to have yet  
chosen a reasonable candidate prefix...)
     def make_tests_...

(I am finding it very curious to be taking a more radically simplistic  
stance than Titus...)

> -> Really glad I'm not using nose.
> Hmmmm...

Yes, it is full of all kinds of general functionality I do not need  
and is missing what I do need, which is why I have my own variant on  
unit test. And which is why I disagree with Jesse that nose is an  
appropriate substrate for functional and device testing. There might  
be a common substrate, but nose, or py.test, as they stand now, and as  
they have signaled their forward directions, are not it.


More information about the testing-in-python mailing list