[py-dev] RFC: V2 of the new resource setup/parametrization facilities

[Carl Meyer]

Hello Holger,

On 06/29/2012 04:55 AM, holger krekel wrote:
> I believe that the new resource parametrization facilities are a major
> step forward - they should allow test writers to much more seldomly having
> to resort to pytest_* hooks, and make access and working with parametrized 
> resources straight forward, irrespective of previous xUnit/pytest background.

I think so too! Very excited about the more straightforward
parametrization and cache-scope for resources.

I'm of course fairly new to pytest and so not as familiar with history
or internal implementation, but perhaps that new perspective is also
useful. On the whole I think the proposal is excellent.

I would also prefer to see pytest.mark.factory_scope and
pytest.mark.factory_parametrize combined into a single decorator, but I
don't like the name "factoryattr". For one thing, I find the usage of
"factory" a bit confusing (there's no clarity about what sort of
factory). And second, I would go even further and allow this decorator
itself (even with no arguments) to mark a function as a funcarg, even if
the factory function is not named according to the pytest_funcarg__foo
convention. So for instance:

pytest.mark.resource()
def database(request):
    # ...

(The decorator could also be "pytest.mark.funcarg()" if you're not ready
to move towards the "resource" naming. I think "resource" is more
intuitive than "funcarg" for newcomers, but I recognize the costs of
shifting.)

And then this decorator would of course also accept the "scope" and
"parametrize" keyword arguments. To my mind, this would be a really nice
unification and could become the canonical way to mark a test resource,
with the naming convention becoming either a deprecated
backwards-compatibility feature, or an approved and supported shortcut
for the no-extra-parameters case, depending how you feel about it.
(Personally I prefer explicit marking to naming conventions, but I
realize this preference may not be in the spirit of pytest).

Regarding the naming of "scope" and the dual scopes (lifecycle and
visibility), personally I don't think it's a big issue to just use the
name "scope"; does the name "scope" actually occur in the API related to
the visibility variety?

I find "cachescope" irritating and a bit misleading. If "scope" is
overloaded, what about "lifetime"? Speaking of the lifetime of an
instance of a test resource feels more natural to me than speaking of
caching it.

Carl