[TIP] Determine test status in tearDown method

Robert Collins robertc at robertcollins.net
Wed Oct 21 14:10:17 PDT 2009

On Wed, 2009-10-21 at 15:54 -0500, Olemis Lang wrote:
> On Wed, Oct 21, 2009 at 3:37 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > On Wed, 2009-10-21 at 15:55 +0200, holger krekel wrote:
> >
> >> I like the idea of systematically allowing test code to signal warnings.
> >> It is then a matter of reporting how/when to present it.
> >
> > This is what I'm working on, but not warnings specifically - any extra
> > data. Do you think such things needs to be categorised as 'warnings' (vs
> > logs/ test data etc?')
> >
> IMHO ... the term warning is just because of an interpretation of the
> semantics of that specific data. If we talk in terms of data , well
> the part of storing warnings messages might fit in there, but not sure
> about the part related to integration with warnings and logging
> modules, and probably about the methods I mentioned in a separate
> thread `tc.warn` and `tc.warnIf` (or whatever they might be ;o).

Integrating with those modules would be (IMO) best done via test helpers
[that the base test case could choose to enable]. As far as emitting a
warning directly to the test framework is concerned, I'd be putting that
on TestResult - again, questioning whether it needs categorisation. And
also whether we need a timeline - I'm trying to choose the smallest
feature set that meets one or more of:
 - regularly needed
 - currently approximated via various ugly means
 - trivial to get for free while we make changes

> What would that fit in there ?
> PS: I don't know anything about the scope of your work in this field

If you haven't read my blog post, please do - I linked it early in this
thread. I'm trying to fix a few key interfaces within unittest which are
making it really really painful to extend.

-------------- 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/20091022/db508f08/attachment.pgp>

More information about the testing-in-python mailing list