Code review comment for lp:~free.ekanayaka/testresources/use-test-case-result

Hi Robert,

below follows a reply from Michael. Would you be fine with using _resultForDoCleanups for now and possibly file a bug as he suggests?

-----------

Hello Free,

Well, inspecting stack frame locals is a horrible way to find the result. :-)

The correct way to change the result class on the runner is to override the _makeResult method. On the other hand I have no intention of removing _resultForDoCleanups so feel free to use it for the moment and file an issue on bugs.python.org to provide a cleaner way (preferably with some explanation of why you need to access the result and can't override _makeResult or use a custom TestSuite that gives you access to the result object).

It really should be possible to control all of the components of a test stack without resorting to trickery and unittest could certainly use some improvement here.

All the best,

Michael

On 14 Aug 2012, at 12:45, Free Ekanayaka <email address hidden> wrote:

> Hey there,
>
> I'm writing you because of this MP:
>
> https://code.launchpad.net/~free.ekanayaka/testresources/use-test-case-result/+merge/119153
>
> Essentially the testresources package currently finds out the test
> result object with this method:
>
> def _get_result():
> """Find a TestResult in the stack.
>
> unittest hides the result. This forces us to look up the stack.
> The result is passed to a run() or a __call__ method 4 or more frames
> up: that method is what calls setUp and tearDown, and they call their
> parent setUp etc. Its not guaranteed that the parameter to run will
> be calls result as its not required to be a keyword parameter in
> TestCase. However, in practice, this works.
> """
> stack = inspect.stack()
> for frame in stack[2:]:
> if frame[3] in ('run', '__call__'):
> # Not all frames called 'run' will be unittest. It could be a
> # reactor in trial, for instance.
> result = frame[0].f_locals.get('result')
> if (result is not None and
> getattr(result, 'startTest', None) is not None):
> return result
>
> which turns to be tad slow, or at least slower then, say, a direct
> attribute access.
>
> I've noticed that in Python 2.7 TestCase instances now have a
> _resultForDoCleanups attribute that we could use. How safe would it be
> to use it? Are there better options coming along? (Robert mentioned a
> plugin system you're working on). In case there's a proper "fix" coming,
> would it be fine to stick to this private attribute access in the
> meantime?