[py-dev] py.test and editors (Re: [issue57] Emacs and py.test tracebacks)
holger krekel
holger at merlinux.eu
Wed Jul 23 14:52:22 CEST 2008
Hi Ralf,
On Wed, Jul 23, 2008 at 14:43 +0200, Ralf Schmitt wrote:
> 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.
The "not complaining" part is not essential to me.
We'll find a good solution i am sure. After all one
could specify "fixed=True", "shouldfail=True" or whatever
once the basic machinery is there to satisfy use cases.
> > 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.
for large projects it could evolve as being really helpful,
particularly if you can also specify platforms.
> >> 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?
yes - but this is not the right thing for packaged
or setup.py installs. One may not have write access
to the installation path for starters. Or no
c-compiler is available on win32 etc.
holger
--
collaborative expert contracting: http://merlinux.eu
PyPy Python/Compiler tool chain: http://codespeak.net/pypy
pylib py.test/greenlets/svn APIs: http://pylib.org
More information about the Pytest-dev
mailing list