@@ -632,6 +632,14 @@ Otherwise, you need to do it manually:
632
632
warnings.warn(' Use new_func instead.' , FutureWarning , stacklevel = 2 )
633
633
new_func()
634
634
635
+ You'll also need to
636
+
637
+ 1. write a new test that asserts a warning is issued when calling with the deprecated argument
638
+ 2. Update all of pandas existing tests and code to use the new argument
639
+
640
+ See :ref: `contributing.warnings ` for more.
641
+
642
+
635
643
.. _contributing.ci :
636
644
637
645
Testing With Continuous Integration
@@ -859,6 +867,55 @@ preferred if the inputs or logic are simple, with Hypothesis tests reserved
859
867
for cases with complex logic or where there are too many combinations of
860
868
options or subtle interactions to test (or think of!) all of them.
861
869
870
+ .. _contributing.warnings :
871
+
872
+ Testing Warnings
873
+ ~~~~~~~~~~~~~~~~
874
+
875
+ By default, one of pandas CI workers will fail if any unhandled warnings are emitted.
876
+
877
+ If your change involves checking that a warning is actually emitted, use
878
+ ``tm.assert_produces_warning(ExpectedWarning) ``.
879
+
880
+
881
+ .. code-block :: python
882
+
883
+ with tm.assert_prodcues_warning(FutureWarning ):
884
+ df.some_operation()
885
+
886
+ We prefer this to the ``pytest.warns `` context manager because ours checks that the warning's
887
+ stacklevel is set correctly. The stacklevel is what ensure the *user's * file name and line number
888
+ is printed in the warning, rather than something internal to pandas. It represents the number of
889
+ function calls from user code (e.g. ``df.some_operation() ``) to the function that actually emits
890
+ the warning. Our linter will fail the build if you use ``pytest.warns `` in a test.
891
+
892
+ If you have a test that would emit a warning, but you aren't actually testing the
893
+ warning itself (say because it's going to be removed in the future, or because we're
894
+ matching a 3rd-party library's behavior), then use ``pytest.mark.filterwarnings `` to
895
+ ignore the error.
896
+
897
+ .. code-block :: python
898
+
899
+ @pytest.mark.filterwarnings (" ignore:msg:category" )
900
+ def test_thing (self ):
901
+ ...
902
+
903
+ If the test generates a warning of class ``category `` whose message starts
904
+ with ``msg ``, the warning will be ignored and the test will pass.
905
+
906
+ If you need finer-grained control, you can use Python's usual
907
+ `warnings module <https://docs.python.org/3/library/warnings.html >`__
908
+ to control whether a warning is ignored / raised at different places within
909
+ a single test.
910
+
911
+ .. code-block :: python
912
+
913
+ with warch.catch_warnings():
914
+ warnings.simplefilter(" ignore" , FutureWarning )
915
+ # Or use warnings.filterwarnings(...)
916
+
917
+ Alternatively, consider breaking up the unit test.
918
+
862
919
863
920
Running the test suite
864
921
----------------------
0 commit comments