[py-dev] RFC: V2 of the new resource setup/parametrization facilities
Floris Bruynooghe
flub at devork.be
Sat Jun 30 02:23:04 CEST 2012
Hello Holger,
On Fri, Jun 29, 2012 at 10:55:23AM +0000, holger krekel wrote:
[...]
> Direct scoping of funcarg factories
[...]
> Direct parametrization of funcarg factories
These two seem fine, but personally I would prefer them to use the
same marker with keyword-only arguments::
@pytest.mark.factory(scope='session', parametrize=['mysql', 'pg'])
def pytest_funcarg__db(request):
...
This seems like a more natural API which collects the different
functions, certainly when using both for one funcarg.
However it bothers me that funcargs now have two types of scope: an
implied scope derived from where it is defined and which defines their
visibility (e.g. only inside a class, module, directory). And then
this new scope which is essentially a caching/teardown scope. The
fact that the ScopeMismatch exception is needed is a result of this I
think.
The previous resource/funcarg split avoided this confusion.
Lastly, when do scoped funcarg resources get invoked? Only at the
time a test function requests it or always at the time when the scope
is entered?
> support for setup_session and setup_directory
> ------------------------------------------------------
[...]
> # content of conftest.py
> def setup_session(db):
> ... use db resource or do some initial global init stuff
> ... before any test is run.
>
> def setup_directory(db):
> # called when the first test in the directory tree is about
> to execute
I think the naming of these functions break the py.test convention,
normally the only functions picked up from conftest.py start with
pytest_. I can certainly imagine a conftest.py or plugin already
having a setup_session function. These are new functions and do not
provide a compatibility API with other testing frameworks, so I think
they would be better named pytest_setup_session and
pytest_setup_directory.
It also feels slightly weird that they do not get their respective
Node passed in. This is a little inconsistent with the current
setup_X method which all take a module, class or method argument. I
can't think of an immediate use for it as you can push out pretty much
everything you need to do to a properly scoped funcarg resource. And
following that reasoning the setup function would end up having no
body at all, which also seems weird.
> Implementation level
> ===================================================================
[...]
> the "request" object incorporates scope-specific behaviour
> ------------------------------------------------------------------
[...]
> In fact, the request object is likely going to provide a "node"
> attribute, denoting the current collection node on which it internally
> operates. (Prior to pytest-2.3 there already was an internal
> _pyfuncitem).
Does this mean you will revert the currently checked-in behaviour
where a Node is actually a Request subclass and is the object passed
to the funcarg resource factories?
Hope this was helpful feedback,
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
More information about the Pytest-dev
mailing list