Merge lp:~free.ekanayaka/testresources/use-test-case-result into lp:~testresources-developers/testresources/trunk

I'm not sure this is supported - its a _ attribute, and the TestCase
API uses public attributes for things that subclasses are meant to
call. Lets get Michael Foords opinion on it before doing it.

Sure, I see the point, but to me accessing that private attribute doesn't seem to leak the underlying implementation any more than traversing the stack looking for a variable with a certain name.

On Tue, Aug 14, 2012 at 4:45 AM, Free Ekanayaka
<email address hidden> wrote:
> Sure, I see the point, but to me accessing that private attribute doesn't seem to leak the underlying implementation any more than traversing the stack looking for a variable with a certain name.

Its looking for a parameter with a certain name, which is due to
keyword parameters, part of the public contract.

Okay fair enough. Shall I get in touch with Michael Foords and ask him how safe/unsafe would be to use that private attribute? or if there is any plan to expose the result object in future Python releases.

On Tue, Aug 14, 2012 at 9:52 PM, Free Ekanayaka
<email address hidden> wrote:
> Okay fair enough. Shall I get in touch with Michael Foords and ask him how safe/unsafe would be to use that private attribute? or if there is any plan to expose the result object in future Python releases.

His plugins branch might do something in that direction. Please do
have a chat to him :)

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?

On Tue, Aug 21, 2012 at 12:16 AM, Free Ekanayaka
<email address hidden> wrote:
> 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?

Sure. Though he has muddled thinking here, because there is no runner
involved. This is purely the TestCase API/protocol interactions.

Yeah, I didn't get that bit too, I thought I might be missing something but now you confirm he was just a touch confused :)

So, where do we want to go from here?

I propose to merge this branch as upstream has confirmed it's fine to use _resultForDocCleanups. I can file a bug to the Python tracker describing our use case and asking to eventually support an API to get the result object.

ok

On Sun, Sep 16, 2012 at 4:33 AM, Free Ekanayaka
<email address hidden> wrote:
> I propose to merge this branch as upstream has confirmed it's fine to use _resultForDocCleanups. I can file a bug to the Python tracker describing our use case and asking to eventually support an API to get the result object.
> --
> https://code.launchpad.net/~free.ekanayaka/testresources/use-test-case-result/+merge/119153
> You are subscribed to branch lp:testresources.