Hi Floris,
On Sun, Aug 05, 2012 at 17:14 +0200, Floris Bruynooghe wrote:
> Hello Holger,
>
> On 4 August 2012 14:13, holger krekel <hol...@merlinux.eu> wrote:
> > On Sat, Jun 30, 2012 at 12:26 +0100, Floris Bruynooghe wrote:
> >> As an aside however, one of my usecases for merged request/item
> >> objects was so I could put setup in a session-wide scoped funcarg but
> >> also automatically request this funcarg based on a mark::
> >>
> >> def pytest_runtest_setup(item):
> >> if 'needsdb' in item.keywords: # or a more explicit API
> >> item.getresource('db')
> >>
> >> I understand that this will still be possible via::
> >>
> >> def pytest_runtest_setup(item):
> >> if 'needsdb' in item.keywords:
> >> item.session.getresource('db')
> >>
> >> Or something similar to that.
> >
> > With the current @setup API this is not possible but it should be. I'd like
> > to understand the exact use case a bit. What do you do with the "db"
> > object here? I guess you cause side effects because you would otherwise
> > just request a funcarg in the tests, right?
>
> Actually there is no side effect here. This was born out of Andreas
> Pelme's desire to be able to mark tests with a marker while trying to
> re-use the session-wide caching that funcargs gave us. But the new
> @setup already covers this case completely since it can handle the
> caching just fine. But I still think this is a nice use-case, since
> it would allow being able to use the same setup and request it with
> either a funcargs or a mark.
But if you request it with a mark, we are talking about side effects, aren't we?
(I'd define "side-effects" as something that doesn't inject a test
dependency directly to a test).
> > If so, then i can imagine the following solution:
> >
> > @pytest.setup(enabled=myhelper)
> > def perform_side_effect_with(db):
> > ...
> >
> > The "enabled" helper would be called during collection so that
> > pytest gets to know which tests will actually execute the setup
> > function and its (potentially parametrized) required resources.
> > It could look like this::
> >
> > def myhelper(collectioncontext):
> > return "needsdb" in collectioncontext.markers:
> >
> > and collectioncontext also carries module/class/function (depending on
> > the scope specified with the setup). If the helper returns True then
> > the setup is considered and thus receives the DB object. Do you
> > think this would solve your use case? (Collectioncontext would not
> > have a addfinalizer() and might in the future offer more collection-specific
> > things).
>
> This does sound like a very neat solution indeed, I think this would
> be a good addition.
OK, i'll see to implement it but i guess it wouldn't be too bad to do
it after a pytest-2.3 release, unless there is a concrete need already.
Btw, if you can find some time sometime to look at a) test
pytest-django with pytest-trunk b) port pytest-django to pytest-trunk
features, that would be super-helpful. My personal target for a release
is end august but not before some more real-world beta usages have happened.
best,
holger
>
> Regards,
> Floris
>
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
