homepage

TextTestResult.__init__(...) calls super(TextTestResult, self).__init__() with no args. If a custom TextTestResult descendant has a complex inheritance hierarchy that puts another class between TextTestResult and TestResult in the __mro__, then that class doesn't receive the common stream, descriptions, and verbosity args. If it needs them to function then the __init__ chain explodes.
See attached breakunit.py for an example of this.

Running your code with 2.7.2 gives:
Traceback (most recent call last):
 File "C:\Programs\Python27\misc\tem.py", line 41, in <module>
 unittest.main(testRunner=runner)
 File "C:\Programs\Python27\lib\unittest\main.py", line 95, in __init__
 self.runTests()
 File "C:\Programs\Python27\lib\unittest\main.py", line 229, in runTests
 self.result = testRunner.run(self.test)
 File "C:\Programs\Python27\lib\unittest\runner.py", line 142, in run
 result = self._makeResult()
 File "C:\Programs\Python27\lib\unittest\runner.py", line 138, in _makeResult
 return self.resultclass(self.stream, self.descriptions, self.verbosity)
 File "C:\Programs\Python27\lib\unittest\runner.py", line 37, in __init__
 super(TextTestResult, self).__init__()
TypeError: __init__() takes exactly 4 arguments (1 given)
Nothing 'explodes', just a normal exception due to what I believe is a programming error on your part that has nothing to do with unittest. The doc for super says
"The second use case is to support cooperative multiple inheritance in a dynamic execution environment. This use case is unique to Python and is not found in statically compiled languages or languages that only support single inheritance. This makes it possible to implement "diamond diagrams" where multiple base classes implement the same method. Good design dictates that this method have the same calling signature in every case (because the order of calls is determined at runtime, because that order adapts to changes in the class hierarchy, and because that order can include sibling classes that are unknown prior to runtime).""
The various __init__ methods, as you know, have different and incompatible calling signatures, hence the exception. I believe this should be closed as invalid. Raymond, as super expert, do I have this right?

I think we'll have to wait for Micheal to double check, but it looks to me like there is a bug in unittest.TextTestResult. TestResult's init expects the three arguments the OP is talking about, but defaults them to None. TextTestResult accepts those three arguments in its init with no defaults, but does not pass them to the base class in the super call. If this is intentional, I would say that it needs to be documented, since it is not obvious why it would be done that way, since it does, in fact, break the "cooperating classes" model required to use super correctly.
(As an aside, I was quite surprised to find TextTestResult in the runner.py file rather than the result.py file within the unittest package.)

I have a feeling I added the arguments to TestResult.__init__ to allow it to be used as a silent test result directly in place of TextTestResult. I still need to check this. 
Not adding the arguments to the super call in TextTestResult would have been an oversight. Let me check this understanding is correct, and if there is no reason for it not to pass on those arguments I'll fix it.

Sorry for any confusion caused by my imprecise use of the word "explodes."

New changeset 0362d64c783a by Michael Foord in branch '3.2':
Closes issue #12376 : Pass on parameters in unittest.TextTestResult.__init__ super call
http://hg.python.org/cpython/rev/0362d64c783a 

Fixed in 2.7, 3.2 and 3.3.1.