On Sat, Jun 30, 2012 at 12:26 +0100, Floris Bruynooghe wrote:
> > On Sat, Jun 30, 2012 at 01:23 +0100, Floris Bruynooghe wrote:
> > > On Fri, Jun 29, 2012 at 10:55:23AM +0000, holger krekel wrote:
> > > >
> > > > 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.
> >
> > I think using pytest_* hooks also has consistency problems:
> >
> > * hooks cannot usually receive arbitrary funcargs
>
> This is why a signature with a request/node for these might be better::
>
> def pytest_setup_session(session):
> session.getresource('db') # or .getfuncargvalue()?
> ...
>
> > * xUnit-style consistency: consider explaining the new functions
> > to someone only knowing setup_module/ class etc.
>
> As I tried to say before, they do not come for xUnit so I don't think
> this is too important. I think the consistency inside conftest.py is
> more important.
Well, pytest introduced setup_module/class and nose/unittest ported it.
I consider setup_directory (or setup_session) to be xUnit consistent
from a user perspective and maybe nose/unittest will also add it - i guess
there are extensions there implementing something like this already.
In generaly, if we go the route of making setup_X more powerful there
probably is less need for pytest_runtest_setup calls. The only difference
would be that runtest_setup is called in plugins/conftest.py whereas
setup_function/method need to be defined around the actual test code.
(TBH i wonder if setup_module/class/function/method could be allowed in
conftest.py files as well - in many cases there are easier to handle
than pytest_runtest_item(item) which does not even guarantee that
the item is a python function - could be a PEP8 checker Item).
> > I am wondering, however, do we even need a "setup_session"? setup_directory
> > should usually be enough, i guess, and it's more unlikely people used
> > that name already (and we could warn about setup_session in 2.X to
> > reserve introducing it in 2.X+1).
>
> Maybe not, but if you don't provide setup_session (or
> pytest_setup_session) then pytest_sessionstart will be used again
> when someone thinks of a reason to use it. And that's what you wanted
> to avoid.
We definitely need to provide prominent examples for whole-session setup
to avoid further usage of sessionstart or configure.
> [...]
> > If a setup-function has no body, then tests could just require it themselves
> > and that'd be enough. If there is a need, we could introduce a marker for
> > requiring funcarg-resources such that tests do not need to require it
> > in their signature.
>
> I'm not sure what that would save, either the test function must
> request the resource or must be marked to need the resource. If
> anything the second takes more work.
>
>
> As an aside however, one of my usecases for merged request/item
> objects was so I could put setup in a session-wide scoped funcarg but
> also automatically request this funcarg based on a mark::
>
> def pytest_runtest_setup(item):
> if 'needsdb' in item.keywords: # or a more explicit API
> item.getresource('db')
>
> I understand that this will still be possible via::
>
> def pytest_runtest_setup(item):
> if 'needsdb' in item.keywords:
> item.session.getresource('db')
>
> Or something similar to that.
It'd probably be best if this requirement is know at collection time so
--collectonly can present the complete picture. This could look like this::
def pytest_itemcollected(item):
if 'needsdb' in item.keywords:
item.applymarker(pytest.mark.needsresource("db"))
Also, the above issue of requiring a global resource could be expressed
like this::
def pytest_collection_finish(session):
session.applymarker(pytest.mark.needsresource("db"))
This should also in principle work well in case of a parametrized "db"
so that all tests requiring "db" can be run multiple times.
(I am not sure if the above already existing hooks fit well for that, however.)
best,
holger
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
