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