On 2 August 2012 18:24, holger krekel <hol...@merlinux.eu> wrote:
> On Thu, Aug 02, 2012 at 13:50 +0100, Floris Bruynooghe wrote:
>> On 2 August 2012 11:44, holger krekel <hol...@merlinux.eu> wrote:
>> > http://pytest.org/dev/setup.html
>> >
>> > Hope the latter begins to make more sense.
>>
>> Yes, it does. I now see the power @setup. One thing you might want
>> to add is compare the module-global setting to simply using the
>> "global" statement inside the setup function.
>
> Do you mean that in the case where the global-setting happens in the
> conftest.py using "global" does not work?
They both work, I meant:
@pytest.setup(scope='module')
def mysetup():
global myvariable
myvariable = 42
vs:
@pytest.setup(scope='module')
def mysetup(testcontext):
testcontext.module.myvariable = 42
Intuitively I would go for the first option and I think most python
developers would as well since it is what they know. I know the
second option, which you demonstrate, is possible from inside a plugin
or a conftest.py but I probably would consider this a bad practice
since they are not logical places to inject globals. Actually
injecting globals seems weird to me, I used to do this when having
plain old unittest but ever since funcargs I just type in the argument
and find that much clearer. So in short, while it is nice you can do
this I don't think it is a great example as, IMHO, it encourages a bad
practice.
Would a better example be checking for a mark on the function and
doing some special setup based on that? Maybe the special setup is
requesting another funcarg/resource? (But there doesn't seem to be an
API on the testcontext to request a custom funcarg/resource. Is this
meant to be disallowed?)
Which brings me onto the next topic, the testcontext object provides
access to .function, which you can use to check marks etc. But when
you had merged items/requests we had access to the item and you where
even talking about having item.applymarker() and a specific API for
inspecting markers. Would it not be nice to have these APIs on
testcontext (if the sope is "function")?
>> Btw, is it a bug in the assertion that when using a global variable
>> the assert-printing does not seem to show the value of that global
>> variable?
>
> I noticed this as well and consider it a bug, yes.
https://bitbucket.org/hpk42/pytest/issue/171/global-variables-are-not-explained-on
>> > I also uploaded a new package pytest-2.3.0.dev8 to be installed
>> > via:
>> >
>> > pip install -i http://pypi.testrun.org -U pytest
>>
>> I was playing with this over lunch and discovered this doesn't work:
>>
>> @pytest.factory(scope='session')
>> def pytest_funcarg__foo():
>> return 42
>>
>> Would it not make sense to allow this (or at least provide a clearer
>> error)? I still like that form because of the grep-ability (doing a
>> 2-line grep is much harder and would still not cover ppl doing "from
>> pytest import factory" etc).
>
> Grepability is an argument. Would adding a "name=..." parameter for
> the factory-decorator help enough? Allowing and advertising
> pytest_funcarg__foo feels strange to somehow taking a fresh look i think.
I would argue the opposite, allowing the @factory decroator on
pytest_funcarg__* seems like a more gentle progression giving more the
impression that it is simply funcargs evolved. To a newcomer it might
otherwise look like funcargs where not thought out fully yet and make
them think py.test just isn't stable enough yet.
>> Also doing this results in setup_module being called twice:
>>
>> @pytest.setup(scope='module')
>> def setup_module():
>> print 'setting up module'
>>
>> I'm not sure what the correct behaviour should be here.
>
> Hum, I think the decorator "consumes" the function and it should not
> be considered for anything else. Do you agree?
Yes, that's probably the best option.
Regards,
Floris
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
