[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
either.
> -> 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:
http://code.google.com/p/python-nose/source/browse/trunk/nose/util.py
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.
-Doug
More information about the testing-in-python
mailing list