[py-dev] RFC: draft new resource management API (v1)

[holger krekel]

Hi Floris,

On Wed, Jun 27, 2012 at 16:59 +0100, Floris Bruynooghe wrote:
> Hello Holger,
> 
> Thanks for the detailed document.  As I understand it the vast
> majority of the functionality is already possible using funcargs.
> Maybe a summary of the benefits over plain funcargs could be helpful?

makes sense.  Maybe some X versus Y examples would help.

> And some guidance for plugin writers on which of the two to choose
> would also be helpful.

Yip.  I think the examples should make it clear that probably the
new API is best fitting in most cases.

> Also, as a general observation I think it will become harder to find
> where a resource factory lives.  Before you could just grep for
> pytest_funcarg__foo which was actually quite nice, certainly when
> you're extending a resource at different levels.  This is still
> possible but not as easy.

Right, the grep-ability was intended behaviour.  It would remain
possible with the new resourcefactory markers i pondered in my
reply to Carl.  Otherwise you would need to invoke "py.test --funcargs"
to get the locations.

> Other then that I've got only one comment really:
> 
> On 27 June 2012 13:57, holger krekel <holger at merlinux.eu> wrote:
> > Setting resources as class attributes
> > -------------------------------------------
> >
> > If you want to make an attribute available on a test class, you can
> > use the resource_attr marker::
> >
> >    @pytest.mark.resource_attr("db")
> >    class TestClass:
> >        def test_something(self):
> >            #use self.db
> 
> I'm not convinced of creating a special purpose mark for this.
> Firstly it seems like an anti-pattern in py.test to me, more like
> xUnit style.

unittest/xUnit-compat is the main idea for this new marker. It would
work on pytest and unittest.TestCase classes alike.  It's also reminiscent
of Rob Collin's testscenario unittest-extension.

> easily done with::
> 
>    class TestClas(object):
>        @classmethod
>        def setup_class(cls, item):
>            cls.db = item.getresource('db')

Not really.  Here we would need to check if the setup_class() 
accepts an item parameter and setup_class methods do not follow
the hook-keyword-arg-calling convention.  Also passing an
item would be slightly arbitrary as the setup_class would
only be called once for all of its test items (functions).

> Also, I realised this API provides for what is probably most of the
> cases of where I want dynamic resources:
> 
> def pytest_setup_init(session):
>     for item in my_item_generator():
>         session.register_resource_factory(item.name, item)

Not sure i understand this idea.  Is it intended as a mixture of 
collection (my_item_generator) and setup (as the hook name suggests)? 

Note that the doc is currently wrong a bit as well - the register_factory
would need to happen at collection-time, not setup-time as the Module.setup()
wrongly suggested.

best,
holger

> (presuming atnode=session is the default)
> 
> 
> Regards,
> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev