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