Thanks Holger,
On Tue, Apr 5, 2011 at 4:16 PM, holger krekel <hol...@merlinux.eu> wrote:
> Hi Vyachselav,
>
> On Tue, Apr 05, 2011 at 11:42 -0400, Vyacheslav Rafalskiy wrote:
>> Hi Holger and list members,
>>
>> I have been using py.test for some time after switching from nose and
>> quite happy with it.
>> However, when migrating from 1.3.1 to 2.0.2 I hit a couple of snags,
>> which makes me hesitate.
>> Perhaps you can help me.
>
> can try but am only online intermittently currently.
>
>> 1. Just to clear the point. I understand from another post that
>> option_xxxx variables
>> in conftest.py are gone and recommended replacement is to use
>> pytest_cmdline_preparse().
>> Is that so?
>
> Not exactly. You can use a .ini file to add command line options:
>
> http://pytest.org/customize.html#adding-default-options
I wouldn't want to maintain an extra config file. I already have
conftest.py with
a lot of hardcoded stuff, a bit more does not hurt. Moreover, if you put it like
def pytest_cmdline_preparse(args):
args[0:0] = [
'--verbose',
'--capture=no',
]
it looks even cleaner than using option_xxxx variables in spite of a
bit of boilerplate.
>> 3. In my pytest_configure() there are numerous conditions when it can
>> fail. For this
>> conditions I have exceptions with specially crafted messages, intended
>> for different
>> people. Now they are gone, replaced by a long and scary listing with every
>> line
>> prepended with INTERNALERROR. What is internal about it? Can I continue
>> managing
>> my configuration errors?
>
> Sure, you should be able to. I guess it was a bit of an incident that
> failures in pytest_configure were shown nicely. I am not quite sure
> immediately what the best way to relay "global" configuration messages
> to the user is. If you'd use "funcargs" and the "session" scope for
> setting up resources then it would show nicely. Feel free to open
> a feature/enhancement request to have py.test show failures
> in sessionstart or configure hooks in a way that helps you.
> This way we can write a specific test and make sure it works
> also in the future.
If I understand correctly, using funcargs means that every test function
of hundreds I have in several suites should include a reference to the
global setup funcarg. It seems a non-starter.
I guess I will stick to the old version and try to think of something
to enter in a feature request.
Vyacheslav
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
