On Tue, 24 Jun 2008 23:03:33 -0000, [EMAIL PROTECTED] wrote:
On 10:05 pm, [EMAIL PROTECTED] wrote:
We need to be especially careful with the unit test suite itself - changing
the test code to avoid the warning will normally be the right answer, but
when the code is actually setting out to test the deprecated feature we
need to suppress the warning in the test suite instead.
This is a dangerous road to go down. If you suppress warnings in the test
suite, you might suppress additional warnings which should actually be
reported. Or, if the API gets modified in some way that the warning is
supposed to be emitted but isn't any longer, it will be silent. It's easy
to accidentally suppress too much or not enough.
The way we've dealt with this in Twisted is adding an 'assertWarns' method
so that we can invoke an API that is supposed to generate a warning, and (A)
that warning and only that *specific* warning will not be emitted, and (B)
if the API stops emitting the warning in the future, the test will fail and
we will notice.
It's also nice to have this facility in the test harness itself, so that you
don't run the additional risk of accidentally (and silently) leaving warning
suppression in place for subsequent tests.
It would be *extra* nice to have this facility added to the standard
library, since assertWarns in Twisted is broken by changes in Python
2.6 (ie, our tests for warnings all fail with [EMAIL PROTECTED]). For now,
we will probably address this by switching to a different warning
API. In the long term, it'd be better for us, other Python developers,
and the standard library if there were an API in the standard library
which facilitated testing of warnings.
Jean-Paul
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
