[ 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