Vinícius Dantas added the comment:
As a last argument:
It is a matter of coherence/consistency with unittest's API, given that
this module does differentiates errors from failures
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Vinícius Dantas added the comment:
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
Changes by Vinícius Dantas <vinicius.gpp...@gmail.com>:
--
pull_requests: +453
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Vinícius Dantas:
Unittest provides us some assert methods, yet one is missing: the
assertDoesNotRaise context.
When running tests, tests may end up as failures, successes or errors. It's
worth noting that errors and failures are conceptually different, and that's
the point
Vinícius Dantas added the comment:
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 <
Changes by Vinícius Dantas <vinicius.gpp...@gmail.com>:
--
pull_requests: +319
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Vinícius Dantas:
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