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?
And some guidance for plugin writers on which of the two to choose
would also be helpful.
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.
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. Secondly if someone wanted an attribute wouldn't this be
easily done with::
class TestClas(object):
@classmethod
def setup_class(cls, item):
cls.db = item.getresource('db')
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)
(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
