Hi Carl,
thanks. I agree on your points and they also connect to comments from Floris.
On Thu, Jul 05, 2012 at 17:35 -0600, Carl Meyer wrote:
> 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.)
I actually think that moving to "resource" and talking about
"funcarg resource" make some sense.
>
> 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.
Ok, so i'd go for:
@pytest.mark.resource(scope=..., parametrize=...)
and also allow using it with no arguments, releasing the requirement
for special naming (which originates from looking at Django FWIW :)
Still pondering if "resourcefactory" would be more suitable, however.
best,
holger
>
> Carl
> _______________________________________________
> py-dev mailing list
> py-dev@codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
