You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make/use test.deprecation.lib; abandon idea to filter by module
This creates a module test.deprecation.lib in the test suite for
a couple general helpers used in deprecation tests, one of which is
now used in two of the test modules and the other of which happens
only to be used in one but is concepually related to the first.
The assert_no_deprecation_warning context manager function fixes
two different flawed approaches to that, which were in use earlier:
- In test_basic, only DeprecationWarning and not the less
significant PendingDeprecationWarning had been covere, which it
should, at least for symmetry, since pytest.deprecated_call()
treats it like DeprecationWarning.
There was also a comment expressing a plan to make it filter only
for warnings originating from GitPython, which was a flawed idea,
as detailed below.
- In test_cmd_git, the flawed idea of attempting to filter only for
warnings originating from GitPython was implemented. The problem
with this is that it is heavily affected by stacklevel and its
interaction with the pattern of calls through which the warning
arises: warnings could actually emanate from code in GitPython's
git module, but be registered as having come from test code, a
callback in gitdb, smmap, or the standard library, or even the
pytest test runner. Some of these are more likely than others,
but all are possible especially considering the possibility of a
bug in the value passed to warning.warn as stacklevel. (It may be
valuable for such bugs to cause tests to fail, but they should not
cause otherwise failing tests to wrongly pass.)
It is probably feasible to implement such filtering successfully,
but I don't think it's worthwhile for the small reduction in
likelihood of failing later on an unrealted DeprecationWarning
from somewhere else, especially considering that GitPython's main
dependencies are so minimal.
0 commit comments