[ python-Bugs-855317 ] unittest: 5.3.9 Getting Extended Error Information

SourceForge.net noreply at sourceforge.net
Sat Dec 6 17:17:48 EST 2003


Bugs item #855317, was opened at 2003-12-06 16:02
Message generated for change (Comment added) made by purcell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=855317&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: unittest: 5.3.9 Getting Extended Error Information 

Initial Comment:
The sample code for getting extended error information
does not appear to work for any useful level of
grouping.  It is ignored by TestSuite and
TestTextRunner.   Other than a direct call to
MyTestCase, no other grouping invokes the
defaultTestResult.

This was reported by Bala on the python-help list.

----------------------------------------------------------------------

>Comment By: Steve Purcell (purcell)
Date: 2003-12-06 23:17

Message:
Logged In: YES 
user_id=21477

Yes, I'd be very happy if you would make the change. Thanks. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-06 20:57

Message:
Logged In: YES 
user_id=80475

Great.  If you would like me to take care of it, assign it back.

----------------------------------------------------------------------

Comment By: Steve Purcell (purcell)
Date: 2003-12-06 17:53

Message:
Logged In: YES 
user_id=21477

Thanks Raymond; I also think that removing the page is the best way to 
proceed. Advanced hackers can read the source, and the vast majority of 
unittest users will not need to know how to get hold of raw tracebacks. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-06 17:43

Message:
Logged In: YES 
user_id=80475

I'm +1 on removing the page because

* adapting the test result has a very limited audience (it
took two years for someone to notice this page was wrong).

* the slightest variant of what you listed quickly takes
someone into the unittest internals and exposing hard to
diagnose tracebacks ('MyTestResult' object has no attribute
'shouldStop')

* the unittest docs already suffer from excess complexity

P.S.  I can make the TeX changes.

----------------------------------------------------------------------

Comment By: Steve Purcell (purcell)
Date: 2003-12-06 16:23

Message:
Logged In: YES 
user_id=21477

Agreed. I've never read this page before, and it is either incomplete or 
of doubtful value to the majority of readers. I suggest either that we 
remove the page, or that it be updated with the following information. 
Fred, if you think the latter is more appropriate, would you be kind 
enough to update the docs? I don't have a tex environment on hand. 
 
Generally speaking, it is the job of a TestRunner to initialise the 
TestResult that will be used, so defaultTestResult() will have no effect in 
most cases. 
 
defaultTestResult() is used when a test case instance is called without 
arguments, e.g. given the code in the docs, and a real test case class 
that looks like 
 
  class MyTestCaseSubclass(MyTestCase): 
      def test_something(self): 
           ... 
 
then a MyTestResult can be conveniently produced by the following code: 
 
  test = MyTestCaseSubclass('test_something') 
  result = test() 
 
A simpler method, which doesn't require overloading defaultTestResult() 
is 
 
  suite = 
unittest.defaultTestLoader.loadTestsFromTestCase(MyTestCaseSubclass) 
  result = suite.run(MyTestResult()) 
 
Also, note that the example code in the existing page of the docs could 
also define MyTestCase more simply as follows: 
 
  class MyTestCase(unittest.TestCase): 
      defaultTestResult = MyTestResult 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=855317&group_id=5470



More information about the Python-bugs-list mailing list