Chris Jerdonek added the comment:
>> what if there are 500 subtests in a loop and you don't want 500 failures to
>> be
>> registered for that test case?
>
> Parametered tests have the same issue. In this case you simply don't use
> subtests
> or test cases.
Right, but then you lose out on both of the benefits documented for subtests:
+Without using a subtest, execution would stop after the first failure,
+and the error would be less easy to diagnose because the value of ``i``
+wouldn't be displayed::
Why tie these together? I'm suggesting that we expose a way to benefit from
the "easy to diagnose" portion without the "suspend stoppage" portion. (The
way we do this doesn't have to be one of the ways I'm suggesting, though I've
suggested a few.)
>> addMessage was just one suggestion.
>
> It is quite orthogonal, actually, and could be added independently. Also, it
> is not clear how you would limit the addMessage to a subtest, rather than the
> whole test case.
It's not orthogonal because the way I suggested it, subTest() would be the
composition of addMessage() and continueTest() context managers. (addMessage
limits itself by being a context manager just like subTest.) So if we added
addMessage() later, we would want to refactor subTest() to be using it. The
equivalence would be something like the following:
with self.subTest(msg=msg, i=i):
self.assertEqual(i % 2, 0)
with self.continueTest():
with self.addMessage(msg, i=i):
self.assertEqual(i % 2, 0)
However, since it looks like we're going with changing the test case ID instead
of putting the extra data only in the exception message (TestCase.longMessage)
like I was suggesting before, I think adding a failFast=True or maxFailures=n
parameter to subTest() has higher importance, e.g.
with self.subTest(msg=msg, maxFailures=1, i=i):
self.assertEqual(i % 2, 0)
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue16997>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
