This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author michael.foord
Recipients Arfrever, Julian, Yaroslav.Halchenko, abingham, bfroehle, borja.ruiz, brett.cannon, brian.curtin, chris.jerdonek, eric.araujo, eric.snow, exarkun, ezio.melotti, fperez, hpk, michael.foord, nchauvat, ncoghlan, pitrou, r.david.murray, santoso.wijaya, serhiy.storchaka, spiv
Date 2013-01-30.17:52:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1359568341.21.0.0857106048955.issue16997@psf.upfronthosting.co.za>
In-reply-to
Content
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.

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*. 

On the other hand if subtests are *better* then lets have them instead - but I'd like to see that discussion happen before we just jump into subtests.
History
Date User Action Args
2013-01-30 17:52:21michael.foordsetrecipients: + michael.foord, brett.cannon, spiv, exarkun, ncoghlan, pitrou, ezio.melotti, eric.araujo, Arfrever, r.david.murray, brian.curtin, hpk, fperez, chris.jerdonek, Yaroslav.Halchenko, santoso.wijaya, nchauvat, Julian, abingham, eric.snow, serhiy.storchaka, borja.ruiz, bfroehle
2013-01-30 17:52:21michael.foordsetmessageid: <1359568341.21.0.0857106048955.issue16997@psf.upfronthosting.co.za>
2013-01-30 17:52:21michael.foordlinkissue16997 messages
2013-01-30 17:52:20michael.foordcreate