[issue30181] Incorrect parsing of test case docstring

[R. David Murray]

R. David Murray added the comment:

Considering that in the cpython test suite we avoid using docstrings in 
unittests because of this "feature" of unittest, I doubt anyone on the core 
team is going to be motivated to fix this :)  That doesn't mean we won't accept 
a PR, but if we do we would only put it in 3.7 because it is a visible behavior 
change, and there are tools that parse unittest output.

--
nosy: +r.david.murray
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30181] Incorrect parsing of test case docstring

[Ben Finney]

Ben Finney added the comment:

> This is because unittest.TestCase method `shortDescription()` will only 
> return the first line of docstring

Yes, that is the “docstring synopsis” I referred to. PEP 257 has a section 
specifically about how tools should parse a docstring: 
https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation

In particular, note that “ Blank lines should be removed from the beginning and 
end of the docstring.”

So, the “first line of the docstring“ for the example 
‘test_reverse_returns_expected_text’ is the text “Should return expected 
reverse text.”.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30181] Incorrect parsing of test case docstring

[Louie Lu]

Louie Lu added the comment:

This is because unittest.TestCase method `shortDescription()` will only return 
the first line of docstring, writing at here*:

"""
The default implementation of this method returns the first line of the test 
method’s docstring, if available, or None.
"""

Not sure if we may change this default behavior for this.



* 
https://docs.python.org/3/library/unittest.html#unittest.TestCase.shortDescription

--
nosy: +louielu

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30181] Incorrect parsing of test case docstring

[Brian May]

Changes by Brian May :


--
nosy: +brian

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30181] Incorrect parsing of test case docstring

[Ben Finney]

New submission from Ben Finney:

The docstring of a test case is not correctly parsed for display.

The attached ‘test_foo.py’ module contains two test case functions. Both 
docstrings conform to PEP 257 : they 
have a single-line synopsis and some extra text in a new paragraph.

However, only one of the functions has its docstring synopsis used in the 
output:

=
==
FAIL: test_lower_returns_expected_code (test_foo.Foo_TestCase)
Should return expected code.
--
Traceback (most recent call last):
[…]

==
FAIL: test_reverse_returns_expected_text (test_foo.Foo_TestCase)
--
Traceback (most recent call last):
[…]

--
Ran 2 tests in 0.001s
=

This violates the docstring parsing as described in PEP 257. The synopsis 
should be obtained by, first, stripping leading and trailing whitespace from 
the docstring; then, from that stripped text, taking the first line as the 
synopsis.

So the expected output for ‘test_foo.Foo_TestCase. 
test_reverse_returns_expected_text’ should include its docstring synopsis, 
“Should return expected reverse text.”

--
components: Library (Lib)
files: test_foo.py
messages: 292387
nosy: benf_wspdigital
priority: normal
severity: normal
status: open
title: Incorrect parsing of test case docstring
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46831/test_foo.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com