Antoine Pitrou added the comment: > 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. ---------- _______________________________________ 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
