[py-dev] new resource API nearing completion including impl
flub at devork.be
Thu Aug 2 00:21:52 CEST 2012
Apologies for not responding earlier, but I've been on holiday. In
general this looks like it is shaping up rather nicely.
My first part of feedback is somewhat bikeshedding-like: while using
the pytest.mark implementation makes a lot of sense I do wonder
whether it does not make more sense to keep the pytest.mark api for
marking test functions and not to start using it for setup/factory
functions. The setup functions would be equally clear when written as
@pytest.factory, @pytest.setup etc and I think keeping the way of
marking test functions with setup/factory functions different is
Secondly, and this could be a bad idea, while I do like the new
decorators I did grow attached to the old pytest_funcarg__* syntax
even if it could be argued they are a bit more magical. Since there
already is a precedent for using __tracebackhide__ I was wondering if
the scoping could be added to the old-style funcargs using e.g.
__scope__ and maybe even __parameterise__ in the function body?
Old-style funcargs could also be made to directly accept other
funcargs/resources I think and so really bridge the gap. I do realise
however that this would probably seem pretty weird to the general
python public and decorators are probably a better api, but I still
wanted to mention this.
A better idea is probably marking pytest_funcarg__* functions with
@factory but I'm failing to use the new-style resources code for now
so not sure if that works.
The setting and parameterisation of a global in the introduction of
@pytest.mark.setup seems very advanced and not very suitable to
introduce the @setup decorator. I'm actually rather dubious to it's
use, it seems very difficult to notice that the test_1 and test_2
functions will be invoked twice. While it is very nice for xUnit
setup functions to have access to funcargs/resources I'm not actually
convinced the decorator version adds much value, they already have an
explicit and well-known scope associated with them via their location.
If there really is a need for modifying the scope or adding
parametrisation (which I'm not sure about, I think funcargs/resouces
could achieve the same in a more obvious way) then just re-using
@factory on the existing xUnit seems like less confusing approach.
I hope this feedback makes sense so far, I apologise if not, I'm
pretty tired right now. I'd really like to have a go at making a
prototype of pytest-django using this in order to give more feedback,
but that's not for tonight. There are a few interesting cases I
encountered there which I should try out and I'm intrigued to see if
the parametrisation would allow it to test multiple db backends in one
process (probably not, but that will be Django's fault, not
On 1 August 2012 14:18, holger krekel <holger at merlinux.eu> wrote:
> Hi all,
> I've just uploaded new docs and my latest changes to the newstyle funcargs
> and setup mechanism. I am getting increasingly happy about it and think
> i solved most of the implementation problems now. I also moved to
> writing direct release-relevant documentation now. The new main doc is
> It contains a number of working examples. To play yourself you can use
> the repo or use "pip install -i http://pypi.testrun.org -U pytest".
> Mostly due to implementation but also for communication reasons
> i resolved to advertising a "newstyle" API that does not fully include
> the oldstyle API. Mainly you cannot use the "request" object in
> setup/factory-marked functions. Intstead there is a more minimal
> "testcontext" object which specifically does not offer
> cached_setup/getfuncargvalue because you can and should now directly use
> funcargs in factory/setup functions. Nevertheless, old-style and
> new-style resources can use each other and i think i managed full
> backward compatibility.
> If i see it correctly there is at least one open issue that was
> originally raised by Floris that is not covered yet: How to write a
> setup-function that instantiates an object depending on the presence of
> a "@needsdb" marker. I have several ideas about this but probably it's
> best to discuss this on IRC ...
> py-dev mailing list
> py-dev at codespeak.net
More information about the Pytest-dev