Option to not-exit on test

[pupeno]

BPO	3379
Nosy	@warsaw, @birkenfeld, @benjaminp, @voidspace
Files	add_avoid_exit_option.diff: Patch to add sption to not-exit on test add_avoid_exit_option.diff: Patch to add sption to not-exit on test, including documentation add_avoid_exit_option.diff: Patch to add sption to not-exit on test, including documentation and tests unittest-no-exit.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/warsaw'
closed_at = <Date 2009-05-02.12:15:35.200>
created_at = <Date 2008-07-16.15:13:21.191>
labels = ['tests', 'type-feature', 'library']
title = 'Option to not-exit on test'
updated_at = <Date 2009-05-02.12:16:25.772>
user = 'https://bugs.python.org/pupeno'

bugs.python.org fields:

activity = <Date 2009-05-02.12:16:25.772>
actor = 'michael.foord'
assignee = 'barry'
closed = True
closed_date = <Date 2009-05-02.12:15:35.200>
closer = 'michael.foord'
components = ['Library (Lib)', 'Tests']
creation = <Date 2008-07-16.15:13:21.191>
creator = 'pupeno'
dependencies = []
files = ['10908', '10909', '10929', '13790']
hgrepos = []
issue_num = 3379
keywords = ['patch']
message_count = 17.0
messages = ['69791', '69792', '69808', '69809', '69896', '69991', '69994', '70032', '70038', '70172', '85726', '86565', '86566', '86605', '86606', '86940', '86941']
nosy_count = 5.0
nosy_names = ['barry', 'georg.brandl', 'pupeno', 'benjamin.peterson', 'michael.foord']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue3379'
versions = ['Python 3.1', 'Python 2.7']

[pupeno]

Added an option, called exit, that when set to false, will make the
tests not exit at the end. This is useful when you are doing Lisp-like
development having a REPL (interpreter/prompt) opened in Emacs and
running the tests over and over on it.
Currently, the tests will exit the interpreter, causing the in-Emacs
interpreter to close as well.
It is by default set to false, so the default behavior is still the
same. When set to true the default behavior shouldn't change much
because at the end of the tests you are going to exit anyway. The only
difference is that no exit code will be provided. There's actually
something else, because the Python test suite hangs in a test case when
this is set to true, but this should be of no concern, as default is false.

[benjaminp]

This is related to (maybe a duplicate of) bpo-2674.

[pupeno]

Indeed this patch can be considered a fix for bpo-2674, but, it should be
documented appropriately. Should that be in
http://docs.python.org/dev/3.0/library/unittest.html ?

[pupeno]

Added some documentation.

[pupeno]

Added tests.

[birkenfeld]

Barry, this looks useful and shouldn't be at all disruptive even after
beta2. May I check it in?

[warsaw]

I'm not sure it's a good idea. When exit=False, don't you lose the
results? It would be better to return the results, but then that makes
for an ugly API (changing the return value based on an argument is a
general no-no in Python).

It would seem better to add a new method that returned the results
instead of exiting. You'd probably want to refactor runTests().

[birkenfeld]

Well, the results are displayed on stdout like they are if sys.exit is
used. As the first post explains, the use-case is running the tests from
an interactive interpreter.

[warsaw]

I still think a different method would be better for the no-exit
functionality.

[pupeno]

What about always returning the results. Granted, when sys.exit is run
there will be no results returned, but then nothing to get the results.
If we divided in two functions, would one be unittest.main and the other
unittest.nonExitingMain? Sounds ugly, but OK if no other better way is
possible.

I personally believe that main should not hijack the current interpreter
with sys.exit at all, but I understand that behavior is not changeable
at the moment (is it?).

[voidspace]

Not returning the results is not a problem - if you needed access to the
results you would hardly be using this API in the first place.

The obvious use case if for running tests from an interactive
environment where you are using the visual output on stdout.

If you want to collect the results you do it programmatically.

I wouldn't be opposed to main() returning the results though, but think
we should apply the patch rather than debate further. To action!

[voidspace]

Patch that adds the same exit functionality, but also stores the result
as an instance attribute on the return TestProgram instance.

As this functionality has been requested several times my intention is
to apply this patch.

[benjaminp]

Michael, this patch seems to include extra addCleanup() stuff.

[voidspace]

Damn somehow managed to upload the patch to the wrong issue twice in a
row. Must have been late at night.

[voidspace]

Correct patch this time. If there are no objections I'll apply this in a
couple of days.

[voidspace]

Committed in revision 71291.

[voidspace]

No, make that revision 72191. :-)