[TIP] RFC: Add TestResult.done()

Robert Collins robertc at robertcollins.net
Thu Apr 9 05:23:13 PDT 2009

On Wed, 2009-04-08 at 17:02 +0100, Michael Foord wrote:
> Robert Collins wrote:
> > JML's testtools has a TestResult subclass with a done() method. The
> > reason for this method is to allow doing things after the last test has
> > run. While a result can infer 'first test' it can't infer 'last test'
> > without ugliness like __del__.
> >
> > Some uses for this are:
> >  - reporting summary data
> >  - closing external resources like log files, sockets to remote machines
> > etc
> >  - <your idea here>
> >
> >   
> Sounds like a straightforward and useful feature request to me. Can you 
> open an item on the Python bug tracker and either assign to me or add me 
> as nosy (michael.foord).


Now, some refinements, as usual (for me at least) when considering a
feature like this from an upstream perspective, where one's immediate
use cases are just special cases not general case, I've come up with
some refinements.

Firstly, I said you can infer starting. But its asymmetrical to have a
'run is finished' method that unittest will call, and not a 'run is
about to start' method too. So I think we should have two methods,
paired. This will avoid people having to write inference code themselves
every time.

Secondly, TestCase.run(None) creates a result. I think it would be good
to make a clear statement about who, and when should and will call these
two new methods. Something like:

"Whomever calls 'start' is responsible for calling 'done'." Concretely
this means that when TestCase implicitly creates a TestResult, it will
call start, and also call done.

Thirdly, naming. I'm agnostic, but I'd lean towards something clear, and
something that can't be easily confused with startTest/stopTest. e.g.
'startTestRun' and 'stopTestRun' (just pluralising 'Test' to 'Tests'
would be easily confusable).

If this all makes sense, I'll write up some tests and put a patch
together. I'm pasting this into the issue to, for folk that watch issues
only :).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20090409/705ce220/attachment.pgp 

More information about the testing-in-python mailing list