Hello Holger, 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 worthwhile. 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 py.test's). 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
