Chris Jerdonek added the comment:
> I am concerned that this feature changes the TestResult API in a backwards
> incompatible way.
My suggestion to add the original TestCase object to TestResult.errors, etc.
instead and add the extra failure data to the longDescription would address
this concern, which is why I suggested it. The former is what currently
happens with multiple failures per TestCase (e.g. in runTest() and tearDown()).
> The underlying idea of subtests is "if you want to parameterize a test,
here is a useful building block".
The current API doesn't seem like a good building block because it bundles
orthogonal features (i.e. to add loop failure data to a block of asserts you
have to use the continuance feature). Why not expose *those* as the building
blocks? The API can be something like--
with self.addMessage(msg):
# Add msg to the longDescription of any assertion failure within.
with self.continueTest(msg=''):
# Keep running the TestCase on any assertion failure within.
(The current subTest() is basically equivalent to continueTest() with a
specialized message. It could be added, too, if desired.) Accepting a string
message is more basic and flexible than allowing only a **kwargs dict, which
seems a bit "cute" and specialized to me.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
