Skip to content

Commit

Permalink
report unhandled exception in testing framework
Browse files Browse the repository at this point in the history
Fixes CleanCut#60 - uncaught exception from testcase - exit without traceback
  • Loading branch information
e3krisztian committed Jun 16, 2015
1 parent 6c72401 commit 572737c
Showing 1 changed file with 12 additions and 5 deletions.
17 changes: 12 additions & 5 deletions green/cmdline.py
@@ -1,6 +1,7 @@
from __future__ import unicode_literals
import os
import sys
import traceback

try: # pragma: no cover
import coverage
Expand Down Expand Up @@ -80,11 +81,17 @@ def main(testing=False, coverage_testing=False):
test_suite = GreenTestSuite()

# Actually run the test_suite
if testing:
result = lambda: None
result.wasSuccessful = lambda: 0
else:
result = run(test_suite, stream, args) # pragma: no cover
# result defaults to a failure
result = lambda: None
result.wasSuccessful = lambda: 0
if not testing:
try:
result = run(test_suite, stream, args)
except:
sys.__stderr__.write(
'Unhandled exception in the testing framework:\n')
tb_limit = None
traceback.print_exc(tb_limit, sys.__stderr__)

if args.run_coverage and ((not testing) or coverage_testing):
stream.writeln()
Expand Down

2 comments on commit 572737c

@CleanCut
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm. What about when we're running tests in subprocesses?

I'm working on writing test cases to cover the single-process condition (which I think your code will handle) and the multiple-process condition.

You can use the g stub to help test in-place code, by the way. It's a lot easier than trying to install your custom changes. ./g -r is a good way to check your coverage for single-process. ./g -r -s 0 is a good way to check your coverage for multiple processes. (You'll see a bunch of unfinished multi-process work not covered -- I'm working on that in another branch right now).

@CleanCut
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'm getting real sick of dealing with single-process logic separate from multiprocess logic. Now may be a good time to just make the default run actually use the multiprocess architecture I have in place (just with 1 worker). Then we can just deal with the multiprocess issues as they come up. Like the fact that a crash in a process that's a worker for a pool gets silently ignored and the worker just gets restarted, unless you do something yourself to handle it.

So that's what I'm experimenting with in conjunction with this catch-unexpected-exceptions idea.

Please sign in to comment.