Debug a failing test<\/h1>\n\n\n\n
One reason you might need the debugger is when one of your tests fails. In our example application, when we run the tests in `StudentTest`, we see that there is a failing test.<\/p>\n\n\n\n Currently, this test fails because the expected average does not match the result of the method `getAverageScore()`, as we can see on line 127. We can use the debugger to find out what the problem is and how to fix it. Let\u2019s navigate to this method so we can set a breakpoint there to see what happens.<\/p>\n\n\n\n We can navigate to the method `getAverageScore()` using Jump to Source<\/em> (\u2318\u2193<\/em> on macOS \/ F4<\/em> on Windows\/Linux) when our cursor is on the method. We can place a breakpoint, either by clicking in the gutter or using the shortcut (\u2318F8<\/em> on macOS \/ Ctrl+F8<\/em> on Windows\/Linux). Place the breakpoint on the first line of the method (line 50).<\/p>\n\n\n\n When we run the test in Debug<\/em> mode (\u2303D<\/em> on macOS \/ Shift+F9<\/em> on Windows\/Linux), execution will stop when it hits the breakpoint, so that we can look at the state of our application. We see inline debugging information in the editor.<\/p>\n\n\n\n Here we see that the list of `testScores` has `size = 3`. We can even click in the editor to expand this list to see details of the values in the list. We also see that `testScores.isEmpty()` evaluates to `false`, and therefore the `return` statement inside that `if` statement is unreachable and greyed out.<\/p>\n\n\n\n In the Debug<\/em> tool window (\u23185<\/em> on macOS \/ Alt+5<\/em> on Windows\/Linux), we see the call stack (the methods that were called) on the left. We can also see information about objects and variables, like the student and their test scores, in this example.<\/p>\n\n\n\n Now, we can step through the code to see what happens, using different step actions.<\/p>\n\n\n\n Use Step Over<\/em> (F8<\/em>) to step over a line and go to the next line, or use Step Into<\/em> (F7<\/em>) to step into a method that is called on a line. In this example, we can step into `getTestScore()` \u2013 which isn\u2019t very interesting. When we step into a method, we can continue stepping to return to the call site once we exit the method, or use Step Out<\/em> (Shift F8<\/em>) to return right away. Notice that the variables and values that are shown inline and in the Debug<\/em> tool window are updated as we step through the program.<\/p>\n\n\n\n Once all the scores have been added, we see that the` totalScore` is 25. And here, we see the problem with our logic: we forgot to divide by the number of test scores!<\/p>\n\n\n\n To fix our problem, we need to divide the total score by the number of test scores. To make sure our intended fix is correct, we can use Evaluate Expression<\/em>. Right-click on `totalScore` in the editor to open the context menu and select Evaluate Expression.<\/em> Alternatively, use the shortcut \u2325F8<\/em> on macOS \/ Alt+F8<\/em> on Windows\/Linux.<\/p>\n\n\n\n If we evaluate `totalScore`, we get 25.0, as we can already see in the debugger. However, we can use Evaluate Expression<\/em> to evaluate other expressions, even ones not currently part of our code. Here we can try out potential solutions. For example, if we evaluate `totalScore \/ testScores.size()`, we get \u201c8.333333333333334\u201d, which is the expected average. <\/p>\n\n\n\n Let\u2019s apply our fix to the code to return `totalScore \/ testScores.size()` instead of `totalScore` from the method `getAverageScore()`. When we rerun the test, we see that it now passes. Note that you might want to run all tests to make sure that your fix has not had any unintended side effects.<\/p>\n\n\n\n Since we no longer need the breakpoint, we can remove it, either by clicking the breakpoint in the gutter or by using the shortcut \u2318F8<\/em> on macOS \/ Ctrl+F8<\/em> on Windows\/Linux.<\/p>\n\n\n\n Now that we\u2019ve fixed our failing test and all the tests pass, let\u2019s see if our application works correctly. Go to the `Main` class and run it, for example, by clicking the Run<\/em> button in the gutter.<\/p>\n\n\n\n When we run the application, we see that there seems to be another problem! Our application throws a `DateTimeParseException`, with the message `Text ‘8.7’ could not be parsed at index 0`. Let\u2019s use the debugger to find out what\u2019s wrong. <\/p>\n\n\n\n Note that we can create a breakpoint right from the console, by clicking the link Create breakpoint<\/em>. This opens the Breakpoints<\/em> dialog, where an Exception Breakpoint<\/em> has been added for the `DateTimeParseException`.<\/p>\n\n\n\n Now, when we run our application in Debug<\/em> mode, execution will stop when and where this exception is thrown, so we can figure out what caused it. Execution stops in the `DateTimeFormatter` class. When we expand the `Exception` in the Debug<\/em> tool window, we see that the `detailMessage` is \u201cText \u201c8.7\u201d cannot be parsed as a `DateTime`\u201d. That makes sense, as the number 8.7 does not represent a valid date.<\/p>\n\n\n\n Reset frame<\/strong><\/p>\n\n\n\n To find out where the incorrect value comes from, we can go back in the call stack. The call stack is shown in the left pane of the Debug<\/em> tool window. We see a round arrow in front of the last method that was called. When we hover over this arrow, we see the option to Reset Frame.<\/em><\/p>\n\n\n\n We can use Reset Frame<\/em> to go back to the previous frame. Let\u2019s do so until we get to the point in our code where we try to parse this value into a date. We will need to drop several frames until we get back to our own code. We see that we try to parse a `LocalDate` on line 38 of our `Main` class.<\/p>\n\n\n\n Note that there are limitations to using Reset Frame<\/em>; it only resets local variables, not static and instance variables. It also won\u2019t undo any side effects of your application, like console output. While this is not relevant in the current example, you should be aware when you use Reset Frame<\/em> in the future.<\/p>\n\n\n\n We are trying to parse a part of a line from our CSV file. Each line has been split into parts. To see all parts of the current line, click the View<\/em> link next to the `parts` variable in the Debug<\/em> tool window. Here we see that \u201c8.7\u2019 is actually a test score, as you might have guessed. We can also see that the line does contain a date, but it is in the next part of the line.<\/p>\n\n\n\n As we can see in our code, we are parsing the same part of the line (`parts[3]`) twice! This looks like a copy-paste error! We should be parsing the part of the line that contains the date, which is `parts[4]`. Let\u2019s fix that by changing line 38 to `var testDate = LocalDate.parse(parts[4]);`<\/p>\n\n\n\n Note that we could have also gone directly to this line in the code from the console, by clicking the link \u201cMain.java:38\u201d in the console. However, it is useful to know how to set a breakpoint for an exception in case you ever need it.<\/p>\n\n\n\n In fact, while we’re here, let\u2019s make sure that we are parsing all the parts of the lines correctly. <\/p>\n\n\n\n As we can see in the code just above (on line 25), our CSV file contains a header. Let\u2019s print this header to the console to make sure we parse each part of the line to the correct field. We could add a `System.out.println()` to our code to print the header, but we don\u2019t want to risk print statements ending up in production! Fortunately, there is a better way to do so.<\/p>\n\n\n\n Let\u2019s create a non-suspending breakpoint, which means that execution will not stop on this breakpoint, and set it to log the line to the console when the breakpoint is hit.<\/p>\n\n\n\n To do so, create a breakpoint on line 27. Right-click the breakpoint and click More<\/em> to open the Breakpoints<\/em> dialog. Unselect Suspend<\/em> to make this a non-suspending breakpoint. Next, select Log<\/em> and Evaluate & log<\/em>. Set the Evaluate & log<\/em> field to `”Header: ” + line` and click Done<\/em>. Notice that the breakpoint is yellow, to signify that this is a non-suspending breakpoint.<\/p>\n\n\n\n Now, when we run the application in Debug<\/em> mode, we see that the header is printed to the console. But so are all the other lines from the file. To print only the header, the breakpoint should be on the next line. We could set a new breakpoint there, but then we\u2019d have to redo the configuration\u2026<\/p>\n\n\n\n Instead of creating a new breakpoint, we can drag and drop the existing breakpoint to the next line, preserving its configuration. <\/p>\n\n\n\n Now, when we run the application in Debug<\/em> mode, only the header is printed to the console. Along with the output of our program, of course. It looks like our fields correspond correctly to the headers of the file.<\/p>\n\n\n\n Let\u2019s run our application again to see if everything is now as it should be. We see that the application runs without errors, but it looks like one of the students has a negative average test score.<\/p>\n\n\n\n That can\u2019t be right! Let\u2019s see what\u2019s going on. We\u2019ll set a breakpoint in the code where we add test scores to the student (line 45 in `Main.java`). When we run our application in Debug<\/em> mode, execution will stop every time this breakpoint is hit. We can click the Resume Program<\/em> button (\u2325\u2318R<\/em> on macOS \/ F9<\/em> on Windows\/Linux), either in the Debug<\/em> tool window, or inline in the editor, to get to the next test score.<\/p>\n\n\n\n Every time we click the Resume Program<\/em> button, we can see the values change both in the inline debugging information in the editor and in the Debug<\/em> tool window. Execution will stop every time it hits this breakpoint, so for every test score. Since there are a lot of test scores in the file, this is going to take a while… <\/p>\n\n\n\n As we are only interested in the test scores for a particular student, we don\u2019t need execution to stop for each test score. Instead of clicking the Resume Program<\/em> button many times in a row to get to the scores we\u2019re interested in, we can use a conditional breakpoint \u2013 which will only halt execution under certain conditions.<\/p>\n\n\n\n Right-click the breakpoint to open the Line Breakpoint<\/em> dialog and edit the configuration for the breakpoint. Since we don\u2019t need execution to suspend until we process this particular student\u2019s test scores, we can set the field Condition<\/em> to `studentName.equals(“Olivia Garcia”)` and click Done<\/em>. <\/p>\n\n\n\n Notice that the breakpoint has a small question mark in it, to signify that it is a conditional breakpoint. Now, when we resume our program, execution will stop only once we get to the test scores for the student whose name we have set in the condition. Here we can see that the test score is negative.<\/p>\n\n\n\n To see whether all test scores for this student are negative, let\u2019s add a watch to the field `testScore`. Adding a watch makes it easier to explicitly watch the value of a field. Right-click on the variable `testScore` in the Threads & Variables<\/em> tab in the Debug<\/em> tool window and select Add to watches<\/em> from the context menu. The watch will be shown in the right pane of the Debug<\/em> tool window. <\/p>\n\n\n\n If needed, select the Layout Settings<\/em> icon at the top right of the Debug<\/em> tool window and select Watches<\/em> in the list, to show watches in the right pane.<\/p>\n\n\n\n When we click Resume Program<\/em> and loop over this student\u2019s scores, we see that all her scores are negative. That would explain her negative average\u2026 <\/p>\n\n\n\n This looks like a problem with the input data. Let\u2019s open the CSV file to correct the scores and make sure Olivia\u2019s scores are no longer negative. We can use multiple carets<\/a> to fix all scores at the same time.<\/p>\n\n\n\n In this example, we can fix our input data ourselves. If you are dealing with user input that you can\u2019t change, consider adding validation to the code, for example, that test scores cannot be negative.<\/p>\n\n\n\n Let\u2019s run our application one more time to see that everything is in order. We see that average scores are printed to the console for all students, and none of the scores are negative. This is how our application is expected to work. <\/p>\n\n\n\n In this blog post, we\u2019ve seen how to use the debugger to find and fix several types of bugs, from problems with the logic in the code, to reasons that exceptions are thrown, and finding problems with input data.<\/p>\n\n\n\n Is there anything else you\u2019d like to learn about the debugger<\/a>? Please tell us in the comments!<\/p>\n\n\n\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Failing-test.png\")
Set a breakpoint<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Breakpoint-in-method.png\")
Run in Debug mode<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Run-in-debug-mode.gif\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Debug-tool-window.png\")
Stepping through the application<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Step-actions.gif\")
Evaluate expression<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Evaluate-Expression.png\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Evaluate-Expression.gif\")
Apply fix and rerun tests<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Test-passed.png\")
Run the application<\/h1>\n\n\n\n
Debug an Exception<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/DateTimeParseException.png\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Create-Exception-Breakpoint.gif\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Reset-Frame.png\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Reset-Frame.gif\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Go-to-line-in-code-from-console.png\")
Print to the console<\/h1>\n\n\n\n
Non-suspending logging breakpoint<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Non-suspending-breakpoint.gif\")
Drag and drop breakpoint<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Drag-drop-breakpoint.gif\")
Checking the functionality of the application<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Negative-average-score.png\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Resume-program.png\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Resume-program.gif\")
Conditional breakpoint<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Conditional-breakpoint.png\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Negative-test-score.png\")
Add watch<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Add-to-Watches.png\")
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Add-pane.png\")
Final check<\/h1>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/04\/Final-check.png\")
Conclusion<\/h1>\n\n\n\n