[issue2578] Figure out what to do with unittest's redundant APIs

[Raymond Hettinger]

Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

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.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
__________________________________