Differences

This shows you the differences between two versions of the page.

--- dev:testing:debugging_perl_unit_tests [2024/11/30 15:54] – add a link sandbergja
+++ dev:testing:debugging_perl_unit_tests [2024/12/01 11:20] (current) – [Using a debugger in Perl unit tests] sandbergja
@@ Line 5: / Line 5: @@
 The following steps work for unit tests (i.e. the tests in Open-ILS/src/perlmods/t).  I don't think they work for the live tests.  These are written using the docker dev containers.  If you use a different development environment, you'll probably have to adjust them.
-If there is a test that already calls the subroutine you're interested in:
+===== If there is a test that already calls the subroutine you're interested in =====
   - Note the filename of the test, and the line number that calls the Perl code you'd like to debug.  In our case, we'd like to investigate ''OpenILS::Application::Storage::QueryParser::remove_search_field'' subroutine, which is currently called on line 25 of t/21-QueryParser.t.
   - Start a docker dev container using the instructions on docker hub
@@ Line 25: / Line 26: @@
   - When you are done exploring: enter ''q''
+===== If you have failing tests =====
+Sometimes your test code or production code will have an error that causes it to die.  Sometimes this will cause multiple tests or subtests to fail.  If this happens, you can run into frustrating situations where you set a breakpoint within a failing test, enter ''c'', and instead of allowing you to debug that line, you get the message "Debugged program terminated."  To avoid this:
+  * Make sure to put your breakpoint before or at the **first** line that is failing, or
+  * If you want to debug, say the second failing test, you can use [[https://perldoc.perl.org/Test::More#SKIP:-BLOCK|Test::More's ''SKIP'' feature]] to skip the first test before starting your debugging session and putting a breakpoint on the second failing test.
 ===== If there is not an existing unit test for the code you want to explore =====