In the more recent past, we had a few incidents where customers and even colleagues found out how to disable the breakpoints in their test scripts in the Squish IDE. Unfortunately, they did not really notice how they were doing this and hence needed a little help to re-enable the breakpoints. So we will now have a look at how it looks like when this feature is active, how the breakpoints can be enabled again and what possible uses this feature has.
How do I know that my breakpoints are all disabled?
The sidebar of the editor shows the breakpoint markers with a blue backslash on top, similar to this screenshot:
This backslash indicates that a feature of the IDE (or rather of the underlying Eclipse framework) has been used to disable all breakpoints.
How can I re-enable stopping the execution at breakpoints?
You re-enable all the breakpoints using the Breakpoints view in the IDE. This view is already part of the Test Debugging perspective in the Squish IDE. You can find it in the top-right area as a separate tab next to the Console view.
Alternatively, you can open the view in any perspective using the Window menu. Select Show View and then Other….
Once you activate the menu item the Show View dialog will be shown. Now type the word Break into the search field to filter the list of views. You can see the Breakpoints entry below the Debug folder here. Select that entry and click the OK button.
Look for an icon in the toolbar of the Breakpoints view with the same backward slash . The button will be pressed down when the feature is enabled . Click the button to change the state, and the icon will change to . In this state all the breakpoints are enabled again.
Why would anyone want such a feature?
Even though this feature can be a little confusing when enabling it unintentionally, it can be quite useful when debugging complicated test scripts.
Imagine you debugged a problem in a piece of code that is being reused at many places. Once you have a fix for the problem, you still want to finish the current test execution so that the AUT gets shut down gracefully and resources get cleaned up. You do not need to remove all the breakpoints if a single button can disable them automatically.
Maybe aborting the test is just fine for you? This feature can still be useful to you. After fixing the problem you disable all breakpoints and can trigger a run of the test case to verify the problem is really fixed and does not cause any new issues. If it turns out that there are new problems or the original problem is not fixed yet, you can easily re-enable the breakpoints and start the debug session just where you left off without having to look through the scripts and create new breakpoints.