[py-dev] unclean shutdown of py.test

[holger krekel]

Hi Gordon,

On Fri, Nov 06, 2009 at 17:11 +1100, Gordon Wrigley wrote:
> Short form:
> I have a test that in some circumstances can't raise an exception, all
> it can do is call stuff.
>
> Currently it calls sys.exit, which is less than optimal.
> Is there a function or series of functions I can call to somewhat
> cleanly shutdown py.test in this situation.

maybe.
 
> Longer form:
> First It is worth noting that we always run py.test with -x, I suspect
> that will have some bearing on what follows..
>
> The application I'm testing calls a bunch of C code via ctypes. In the
> event of certain pathological failures that C code does an internal
> error operation equivalent to assert, i.e. print some stuff and then
> call exit.
> When this happens there is no way to unroll the C stack to get back to
> the calling python context and notify py.test of the failure.
> What I have managed to do is intercept the error, and from the
> intercept use ctypes callback functionality to call into a python
> handler.

If you have os.fork ... what happens if you run with the "--boxed" option? 

> It would be nice if I could raise an exception there and use that to
> get back to the original python context, ...

You can't normally do that with today's Python interpreters.  
The "--boxed" above looks like the beginning of a clean solution 
to the problem:  Tests are run in a separate process so that
reporting is safe from running weirdness.  The current --boxed is 
somewhat limited but it implements this idea. 

> that, instead it captures, prints and discards the exception before
> returning to the C context.
> I have sent them an idea I have for how the exception could instead
> optionally be propagated past the C and back to python using setjmp /
> longjmp, but I'm not really hopeful that that will be a viable
> alternative.
> So what I would like to do is clean up py.test in the callback. My
> ideal outcome would be if I could do some small amount of stuff that
> would make py.test act as if it were exiting due to a failed test
> while running with -x.
> Is this line of approach at all possible? or does it violate the
> py.test structure too much to be workable?

Actually i'd like to improve on the idea of running tests and 
reporting about it in separate processes.  

Btw, the next level of distributed testing i see in the dynamic
setup of environments (via virtualenv or buildout) and running
tests there, reporting back to console.  

best,

holger