This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rbcollins
Recipients michael.foord, olemis, rbcollins
Date 2009-04-09.12:23:11
SpamBayes Score 8.63587e-12
Marked as misclassified No
Message-id <1239279792.97.0.0128666336525.issue5728@psf.upfronthosting.co.za>
In-reply-to
Content
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 :).
History
Date User Action Args
2009-04-09 12:23:13rbcollinssetrecipients: + rbcollins, michael.foord, olemis
2009-04-09 12:23:12rbcollinssetmessageid: <1239279792.97.0.0128666336525.issue5728@psf.upfronthosting.co.za>
2009-04-09 12:23:12rbcollinslinkissue5728 messages
2009-04-09 12:23:11rbcollinscreate