homepage

> I am concerned that this feature changes the TestResult API in a
> backwards incompatible way. There are (quite a few) custom TestResult
> objects that just implement the API and don't inherit from TestResult.
> I'd like to try this new code with (for example) the test result
> provided by the junitxml project and see what happens.
Feel free to do it, of course :-)
In any case, we can add a hook to the TestCase subclass so that
specialized reporters can get at the parent TestCase.
(and I'm not sure how it's backwards incompatible: as long as you don't
use subtests, nothing should break - so existing software shouldn't be
affected)
> I have a broader concern too. I have seen lots of requests for "test
> parameterization" and none *specifically* for sub tests. They are very
> similar mechanisms (with key differences), so I don't think we want
> *both* in unittest. If test parameterization is more powerful /
> flexible then I would rather see that *instead*. 
The underlying idea of subtests is "if you want to parameterize a test,
here is a useful building block". Generic parameterization APIs are
cumbersome and actually *harder* to write (and read!) than the
corresponding `for` loop. With subtests, you just write your `for` loop
and use a subtest to isolate each iteration's failures.