On 10:05 pm, ncoghlan at gmail.com 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4