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