[py-dev] new resource API nearing completion including impl

[holger krekel]

Hi Again,

On Thu, Aug 02, 2012 at 07:36 +0000, holger krekel wrote:
> Hi Floris,
> 
> On Wed, Aug 01, 2012 at 23:21 +0100, Floris Bruynooghe wrote:
> > Hello Holger,
> > 
> > Apologies for not responding earlier, but I've been on holiday.
> 
> You are just-in-time right for this.  It anyway took me a while
> to sort out impl issues.
> 
> > 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
> > worthwhile.
> 
> Good point!  Apart from confusingness, The features of applying marks to
> classes or modules are of no use here.  Making them pytest.X functions
> also allows a more concise and better documented signature. Very good
> bikeshedding! :)

I've now implemented the move to @pytest.factory and @pytest.setup and 
also updated and refined the documentation a bit, see:

    http://pytest.org/dev/resources.html

and the new

    http://pytest.org/dev/setup.html

Hope the latter begins to make more sense.

I still intend to refine docs and add more examples but now is lunch and
then child-care summer party time :)

I also uploaded a new package pytest-2.3.0.dev8 to be installed
via:

    pip install -i http://pypi.testrun.org -U pytest

best,
holger


> > 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?
> 
> Not really possible i think.  Traceback-printing has the frames at
> hand to look at locals().  When the namespace of a module is scanned
> the bodies of functions are opaque. 
> 
> > Old-style funcargs could also be made to directly accept other
> > funcargs/resources I think and so really bridge the gap.
> 
> Didn't document it but old-style funcargs do accept other funcargs actually.
> 
> > 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.
> 
> My goal when designing the last incarnation of the API was to make it
> easy for newcomers.
> 
> > 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.
> 
> Why does it not work for you? (Ping me on IRC maybe).
> 
> > 
> > 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.
> 
> Good point again.  I was focused on the difficult cases first -
> the @setup documentation is utterly lacking, sorry about that.  
> Probably it should go to its own page and fully document all xunit
> functionality.
> 
> > 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.
> 
> Maybe i am wrong but I guess you got this impression because i 
> didn't document the wide range of uses of the setup functions.  It's
> actually a feature that you can define per-function/per-class/per-module
> setup code in conftest.py files or plugins.  It is to replace almost all
> uses of implementing pytest_runtest_init/pytest_sessionstart.
> 
> > 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.
> 
> The main difference between setup and factory/funcargs is that setup
> performs side-effects so test functions do not need to list funcargs in
> their signature.
> 
> > 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
> > py.test's).
> 
> Your feedback as always is very valuable, thanks for taking the time!
> As to Django, maybe Carl can help by stating his guess if it's possible at all
> to successively instantiate Django with different backends within
> one process.  
> 
> best,
> holger
> 
> > 
> > Regards,
> > Floris
> > 
> > 
> > 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
> > >
> > >     http://pytest.org/dev/resources.html
> > >
> > > 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 ...
> > >
> > > best,
> > >
> > > holger
> > > _______________________________________________
> > > py-dev mailing list
> > > py-dev at codespeak.net
> > > http://codespeak.net/mailman/listinfo/py-dev
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> > 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>