On 09/02/2010 21:50, Ben Finney wrote:
Michael Foord<mich...@voidspace.org.uk> writes:
It seems to me that the same effect (always reporting test name) can
be achieved in _TextTestResult.getDescription(). I propose to revert
the change to TestCase.shortDescription() (which has both a horrible
name and a horrible implementation and should probably be renamed
getDocstring so that what it does is obvious but never mind) and put
the change into _TextTestResult.
I understood the point of ‘TestCase.shortDescription’, and indeed the
point of that particular name, was to be clear that some *other* text
could be the short description for the test case. Indeed, this is what
you've come up with: a different implementation for generating a short
description.
The default implementation uses *part of* the docstring (the PEP 257
specified single-line summary), but that's just one possible way to make
a short test case description. Calling it ‘getDocstring’ would not only
be disruptive, but clearly false even in the default implementation.
I'm not actually suggesting doing that - I was just musing out loud. So
do you think the *new* implementation would be better, given that it
breaks part of the twisted test suite, or would you be fine with me
putting the current change into TestResult instead?
Given that the change broke something, and the desired effect can be
gained with a different change, I don't really see a downside to the
change I'm proposing (reverting shortDescription and moving the code
that adds the test name to TestResult).
Michael
I've overridden that method to provide better, more specific, test case
short descriptions, and the name works fine since I'm providing an
overridden implementation of “the short description of this test case”.
I've even presented a patch to the third-party ‘testscenarios’ library
to decorate the short description with the scenario name.
I'd suggest this method, with its existing name, is the correct way to
embellish test case descriptions for report output.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
