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 _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev