Mailman 3 June 2011 - pytest-dev

[py-dev] error in teardown wrongly reported as error in setup
by Ralf Schmitt June 10, 2011

June 10, 2011

1 0

Re: [py-dev] Decorators and funcargs in py.test
by Ronny Pfannschmidt June 6, 2011

June 6, 2011

On Mon, 2011-05-30 at 16:23 -0400, Vyacheslav Rafalskiy wrote: > No problem. Here is my (real life) example. > > My functional test functions may or may not return for different > reasons (like a faulty web application or middleware). I want to > declare a fail if it takes more than so many seconds to complete. So I > write a decorator > run_with_timeout(), which will start the function in a new thread and > abandon it after timeout. This can easily be solved by combining something like pytest.mark('timeout') and a override to pytest_pyfunc_call using it i suppose this could also take a look at extending the "--boxed" mode (which forks for each test and uses subprocesses but doesn’t handle timeouts atm. > > A I stated in OP, it is not that I cannot do it. I can and I do. My > point is that it makes sense to allow decorators and should not be > very difficult (see the example in OP). personally i am opposed to creating new data conventions for problems that can be solved with plain marks + a hook usually there are 2 reasons people use to decorate tests my opinions for implementing those are a) add arguments + their cleanups -> funcargs please, they are made for that b) use more sophisticated call's -> hooks please, maybe add a bug ticket for empowering one to return a exception-info, so stuff like thread-wrappers can pass that more nicely for failures *i* really think it is wrong to decorate test functions that way and expect stuff to work there are already plenty of mechanisms to change the behavior of pytest test function calling in the desired way, none of those require hacks to pass around argspecs -- Ronny > > Thanks, > Vyacheslav > > On Mon, May 30, 2011 at 3:55 PM, Ronny Pfannschmidt > <Ronny.Pfannschmidt(a)gmx.de> wrote: > > Hi, > > > > can you try to explain the usecase those decorators are fulfilling, > > > > there may be a better integrated way using pytest.mark + setup/teardown > > hooks > > > > -- Ronny > > > > On Mon, 2011-05-30 at 15:17 -0400, Vyacheslav Rafalskiy wrote: > >> Hi Holger, > >> > >> I am trying to make decorators work with test functions, which depend > >> on funcargs. As it stands, they don't. > >> Decorated functions lose funcargs. A workaround would be to decorate > >> an internal function like this: > >> > >> def test_it(funcarg_it): > >> @decorate_it > >> def _test_it(): > >> # test it > >> > >> _test_it() > >> > >> This works, but it is not nice. I'd rather wrote a decorator like > >> > >> def decorate_it(f): > >> def _wrap_it(*args, **kwargs): > >> # wrap f() here > >> > >> _wrap_it._varnames = _pytest.core.varnames(f) > >> return _wrap_it > >> > >> and apply it straight to the test function. > >> > >> After examining the source code I even expected it to just work > >> (magically of course) but it didn't. > >> Do you think it is worthwhile? If so I can enter a feature request. > >> > >> Thanks, > >> Vyacheslav > >> _______________________________________________ > >> py-dev mailing list > >> py-dev(a)codespeak.net > >> http://codespeak.net/mailman/listinfo/py-dev > > > >

3 8

[py-dev] migration from 1.3 to 2.0
by Vyacheslav Rafalskiy June 1, 2011

June 1, 2011

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. 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? 2. The new behavior is that even if you run py.test --help, the pytest_configure() is still run. In my case pytest_configure() does quite a bit of heavy lifting and raises exceptions at wrong parameters. The result is that if the parameter is wrong I cannot use help to find out what is the right parameter. Of course, the workaround could be: def pytest_configure(config): if config.getvalue('help'): return ... but it seems ugly. Am I in a wrong hook? 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? Thanks, Vyacheslav

2 13