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

[Ralf Schmitt]

On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:

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

It looks like you want that decorator to attach more information to
test functions.
In the case where you only want to mark a test as expected failure, I
think it should be removed.

> 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,

-0 for not complaining when it passes
I don't like that idea, but I also currently don't have the time to
argue about it. twisted's trial raises an error for expected failures
that succeed.

>
>    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.

I would have used that a few times in the past..but I can surely live
without such a feature.

>> 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.

I thought the trick was that it automatically compiles the c modules
on demand when it is imported?