Provide an option for easy instrumenting of resource setup and teardown

On Thu, 2008-10-16 at 00:45 +0000, Jonathan Lange wrote:
> Public bug reported:
>
> When debugging failures to do with strange resource behaviour, it would
> be great to be able to flick a switch and see when resources are created
> and destroyed.
>
> Something similar to the Zope test runner's output for layer setup and
> teardown would be an OK start.

Agreed. Providing a template function approach to setup and teardown
rather than an override-this-function would make this easy.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

The OTS has a result object, so we can try to do something smart and send the information to the testresult object.

(Man, one of these days I'm going to write my own testing framework that's not pyunit.)

On Thu, Oct 16, 2008 at 12:14 PM, Robert Collins
<email address hidden> wrote:
> On Thu, 2008-10-16 at 00:45 +0000, Jonathan Lange wrote:
>> Public bug reported:
>>
>> When debugging failures to do with strange resource behaviour, it would
>> be great to be able to flick a switch and see when resources are created
>> and destroyed.
>>
>> Something similar to the Zope test runner's output for layer setup and
>> teardown would be an OK start.
>
> Agreed. Providing a template function approach to setup and teardown
> rather than an override-this-function would make this easy.
>

Good call.

Are you planning on doing this?
[Man, I really think 'assigned to' in bug trackers is a misfeature-for-managers.]

I had a couple of thoughts on configuration...

we could use hooks, as a kind of semi tolerable global state.

Or we could extend the protocol more deeply and say that we'll emite to the TestResult object being used, IFF it supports an additional function[s] for recording TestResources.

So updating the TestResult protocol to report on TestResource activity is interesting. There is however one key aspect that is problematic: run()/__call__() doesn't pass the TestResult object through to the test, setup, and teardown methods. In particular, we'd want it in setup and teardown.

Some thoughts:
 - we could look up the stack to find the result object.
   a bit gross, but only twice per test object.
 - we could just not report when OptimisingTestSuite isn't being used
   counterintuitive.

Opinions solicited.

We chatted about this on the phone. I think the least bad of these is looking up the stack to find the result object.

Done. Review needed.