Message180977
| 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:21 | michael.foord | set | recipients:
+ 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:21 | michael.foord | set | messageid: <1359568341.21.0.0857106048955.issue16997@psf.upfronthosting.co.za> |
| 2013年01月30日 17:52:21 | michael.foord | link | issue16997 messages |
| 2013年01月30日 17:52:20 | michael.foord | create |
|