[py-dev] py.test and editors (Re: [issue57] Emacs and py.test tracebacks)

[holger krekel]

Hi Ralf, 

On Wed, Jul 23, 2008 at 13:04 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 12:41 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi Ralf,
> >> The ability to mark test cases as "expected failures" would be nice.
> >
> > Yes, i also want something where i can checkin tests
> > that are marked as bugs and have some clever reporting
> > anhd command line options for this (at best even
> > be able to have a link to an issue tracker).
> >
> > maybe:
> >
> >    @py.test.mark(bug=number or string, url=URL)
> >    def test_something():
> >        ...
> 
> I've written a quick hack (which doesn't integrate nicely with
> py.test). It can be viewed here:
> http://code.pediapress.com/hg/mwlib/file/b75d189a01a2/mwlib/xfail.py
> It checks the functions docstring for a link to the issue tracker. I'm
> not quite sure if you want to have that decorator take an issue
> number/link. When you've fixed that bug, you'll remove the decorator
> and loose that valuable information.

I think it's fine to have the decorator mostly stay forever.  

I think that py.test should usually always run the 
"bug" test but report them specially (no tracebacks) 
if they fail and maybe 

    .........bb...................

for the progress bar etc.  However, py.test would not
complain if it passes.  Then, for example, 

    py.test --bugs=173,...,...

would run all tests that are marked with these bug numbers
and turn on full traceback reporting when they fail.  

There are also other things that i'd like to tell 
py.test about a test, e.g. having it run "boxed", 
i.e. isolated so that it can segfault without 
disrupting the testing process. 

> > although i would like this to also work in setup_*
> > functions and in python 2.3 nicely, i think.
> > I imagine such a decorator to just set attributes
> > on the function, not provide a new function.
> > and the py.test machinery to recognize these
> > attributes.  Makes sense?
> 
> sounds good.
> 
> >
> > Not sure i'd like to consider this for 0.9.2 to be honest
> > which i rather want to be a bugfix release - at least
> 
> ok.
> 
> > not to introduce new concepts.  But i am also heavily
> > working on a cleanup / refactoring branch which i
> > consider the base for a 1.0 hopefully not too far
> > in the future.
> 
> nice.
> Is there a list of active branches? the last time I looked at the svn
> repo, trunk looked very quiet (or I used a bad path).

I just removed some branches in svn/py/branch which i think were 
already merged.  py/trunk is mostly what is in 0.9.1 plus a
few more improvements (and hacks).  Active development i 
currently do in the event branch which i'd like to 
merge to trunk hopefully soon. 
 
> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
> the greenlets module is not installed correctly. I haven't looked into
> this (python setup.py install works). But I will probably have a look
> at it in the next days....

cool.  You may just work in release/0.9.x or branch off from there. 
The current way of compiling c-extension modules is a hack IIRC ... 
mostly because i am a bit clueless on how to this correctly,
particularly for win32. 

best, 

holger