[TIP] Generating tests, II (was: Re: Meta-test methods...)
dgou at mac.com
Fri Apr 24 12:02:04 PDT 2009
On or about 2009 Apr 24, at 2:32 PM, C. Titus Brown indited:
> On Fri, Apr 24, 2009 at 12:01:35AM -0400, Douglas Philips wrote:
> -> I said that checking a test method
> -> for being a generator was a hack, seeminly cool at first, but upon
> -> further thought it is just as a proof of concept that it is
> useful to
> -> have a way to dynamically generate a sequence of test methods/
> -> Testing only for generators is both opaque and, critically, fails
> -> generalize to arbitrary python sequences.
> This might be a discussion better carried out on nose-dev, but:
Well, maybe, but I want this kind of functionality in my almost-
vanilla-unittest framework. :)
> isn't one issue that generators are the only "iterator-like"
> function to
> have a clear signature at the time of definition? Specifically, how
> else can I know that a test_* function was a test generator rather
> a function executing a single test?
This is precisely why I suggested using a decorator. You shot that
down as not being 2.3 compatible. Fair enough. The existing unittest
framework uses a naming convention (setUp, tearDown, test...) to
identify the methods it should call and the semantics it expects from
them. Using the generator-ness of a test method to treat it
differently is overloading the testing mechanisms in a bad way. (more
> 'yield' makes the function have a generator type, which is kind of
> to realize -- I hadn't thought of yield as being an implementation of
> function typing in Python before ;)
Not until 2.6 (IIRC) is there a defined way of asking that question.
nose and py.test both have code that grunge around to determine that
in other environments (IronPython, older versions of python, etc).
> Anyway, I can't think of a way to write a wrapper that would be able
> make that distinction for your code below without actually running the
> function and trying to iterate over what it returned. That might be
> reason why nose does things the way it does.
I can. Use a decorator to declare your intent (Explicit is better than
implicit). However I think it is also reasonable to have a separate
naming convention. When I go to read some test code, the existing
naming convention is a great help to understanding it. I know what
setUp is about and when it is call, same for tearDown, and same for
test... methods. Except, well, in this one case, a test... method
means something very different and at a different meta-level.
Even if 'isgenerator' is nice and cleanly abstracted away, it still
wrong to use it:
Whether a particular meta-test-sequence-returning-function
(MTSRF) returns a list, tuple, other sequence-supporting type, or a
generator, is an implementation detail that should not change how the
result is used or even if it is used.
Sure its a cute hack to use generators that way, but it would be just
as simple to use a unique prefix. Then, if you find a generator is the
best way to implement a particular MTSRF, you are free to do so, and
if returning a tuple is clearer, you don't have to worry that your
implementation decisions are going to have unintended side-effects.
More information about the testing-in-python