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 rhettinger
Recipients benjamin.peterson, gvanrossum, purcell, rhettinger
Date 2008-04-08.05:43:58
SpamBayes Score 0.039217502
Marked as misclassified No
Message-id <1207633440.46.0.931981705543.issue2578@psf.upfronthosting.co.za>
In-reply-to
Content
See http://bugs.python.org/issue2249 for discussion.

Personally, I prefer minimalism and would like the API thinned 
considerably.  Also, I don't think all of the classes should be 
exposed.  AFAICT, nobody cares about test suite objects, test result 
objects, and test loader objects.  These are really artifiacts of an 
implementation originally designed to demonstrate how a unittest suite 
could be implemented.   

In Kent Beck's book on Test Driven Development, he complains that most 
unittest implementations spawned from his original work have grown far 
too complicated and would be better served by sticking to a simple 
framework for writing and running tests.

Some of that may have been lost in a effort to model J-Unit or to 
expose all the parts in support of people who want to use subclassing 
to write their own unittest variants and extensions (I have seen this 
in practice but it is somewhat rare). 

If making big changes to the unittest API is on the table, it is worth 
considering alternatives like py.test which is more powerful, easier to 
learn, much less verbose, and more in line with the way python is 
usually written.
History
Date User Action Args
2008-04-08 05:44:00rhettingersetspambayes_score: 0.0392175 -> 0.039217502
recipients: + rhettinger, gvanrossum, purcell, benjamin.peterson
2008-04-08 05:44:00rhettingersetspambayes_score: 0.0392175 -> 0.0392175
messageid: <1207633440.46.0.931981705543.issue2578@psf.upfronthosting.co.za>
2008-04-08 05:43:59rhettingerlinkissue2578 messages
2008-04-08 05:43:58rhettingercreate