On Thu, Jun 28, 2012 at 08:15 +0000, holger krekel wrote:
> I am still fine to consider e. g. the introduction of a pytest.current
> namespace. It could lead to make setup_X methods more powerful::
>
> import pytest
> def setup_module(): # pytest accepts it to keep nose compat
> db = pytest.current.modulenode.getresource("db")
>
> The "current" namespace could be set by the respective node setup
> methods. For classes it's the same idea::
>
> class TestClass:
> def setup_class(cls):
> cls.db = pytest.current.classnode.getresource("db")
>
> Due to the non-declarative nature of this approach, however, i don't
> see a way to rerun the testclass with multiple "db" instances.
Actually i see a way :)
@pytest.mark.uses_resource("db")
class TestClass:
...
This would signal pytest that this class is (somehow) using
the parameter "db" and thus collect multiple variations if the
resource is parametrized at register_factory time. Of course,
plugins such as pytest-django would be able to declare this resource
usage automatically, reducing boilerplate for test writers.
What do you think?
holger
> On a side note, many Java programmers have gone from the old JUnit
> approach to TestNG, see the wikipedia entries. py.test rather
> goes for similar ideas as TestNG.
>
> best,
> holger
>
> >
> > >> 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)?
> >
> > My bad for writing a bad example, I shouldn't have used the word
> > "item" in there. Anyway the main point is that thanks to
> > .register_resource_factory() taking the name of the resource as an
> > argument I believe most, if not all, the cases where I wanted to
> > create funcargs/resources without knowing what they where beforehand
> > are solved.
> >
> >
> > 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
