I have been browsing around the unittest standard library, and I realized that TestCase's shortDescription() method at lib/pythonX.X/unittest/case.py returns None when the there is no docstring on the test that is running.
As shortDescription() should obviously return a string, I would recommend returning an empty string instead of None when no docstring is found.
This came to mind when I was using testscenario package, which only displays the scenarioname when shortDescription() returns something but None.
When we are starting from scratch a test suite, docstrings are left for another stage, when we have running (probably failed, if we are TDDing) unittests.
Last yet not least, I am sure it's a good practice to avoid returning None, which forces None-checks, returning empty strings, lists, objects of the return type expected from that function.

This can break a code that checks whether shortDescription() is None.

If you an empty string rather than None, just use the expression `shortDescription() or ''`.

It's too late to change this API.  As Serhiy says, it risks breaking code that is currently running and correct.

Note the the __doc__ on functions is set to None when there is no docstring.  For better or worse, returning None is common in the Python world.

If it is tagged for future releases, whoever choose to update their Python
version should expect code breaking and API changes, shouldn't them? I
don't see code breaking as an issue against this request.

On 1 March 2017 at 14:33, Raymond Hettinger <report@bugs.python.org> wrote:

>
> Raymond Hettinger added the comment:
>
> It's too late to change this API.  As Serhiy says, it risks breaking code
> that is currently running and correct.
>
> Note the the __doc__ on functions is set to None when there is no
> docstring.  For better or worse, returning None is common in the Python
> world.
>
> ----------
> nosy: +rhettinger
> resolution:  -> rejected
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue29686>
> _______________________________________
>

-- 
Vinícius Dantas de Lima Melo
Graduando em Ciências e Tecnologia
Universidade Federal do Rio Grande do Norte (UFRN)
Escola de Ciências e Tecnologia (ECT)
Natal, Rio Grande do Norte
vinicius.gppcom@gmail.com viniciusdantas@bct.ect.ufrn.br
vinicius.dantasdelimamelo@mail.utoronto.ca | Celular/Mobile Phone: +1 647
447 5737
Skype: viniciusdantas01

We don't make breaking changes unless there is strong motivation, which is lacking here.

In the point of view of a tester, if it's an error, they will know right
away it is a test case problem, not an assert problem. That makes debugging
easier.
It is also important to note that, if it's an AssertionError, we may add a
message. While, if it is an error, no message would be displayed but the
original Exception's.

As Selenium's example, as I said, was just a use case example.

Finally, having the failure reason explicit is better than keeping it
implicit.