Differences

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

--- dev:testing:debugging_perl_unit_tests [2024/11/29 21:57] – created 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 =====
@@ Line 61: / Line 68: @@
 If it relies on a complex object, but you can pass it in, you can use ''Test::MockObject''.  If it relies on a complex object but it is setup somewhere you can't control in your test (e.g. the initializer creates a new CSTORE editor), use ''Test::MockModule''.
+===== Further resources =====
+* [[https://www.youtube.com/watch?v=LtAGbUYTnR0|The Perl 5 Debugger by Ricardo Signes]] (youtube video) -- a good talk on the Perl debugger
 {{tag>automated-tests}}