![]() |
JSwat ProjectTesting Breakpoints |
Start these tests by bringing up the breakpoints manager dialog, which is found under the "Debug" menu as the menu item "Breakpoints...". These are also found in the "Breakpoints" panel.
This dialog/panel shows a list of the defined breakpoints. Its
contents should be the same as the output from the
"stop
" command. Double-clicking on a
breakpoint in the list should present the breakpoint properties
dialog.
Presents an identical dialog to that described here. Use that test case to test this dialog. After adding a breakpoint, it should appear in the "Default" breakpoint group in the manager dialog.
Presents a dialog asking the user for a breakpoint group name and a select box to choose the group's parent group.
Presents a dialog showing the selected breakpoints properties.
Disables the selected breakpoint or breakpoint group.
Enables the selected breakpoint or breakpoint group.
Removes the selected breakpoint or breakpoint group.
This section is to confirm that breakpoints can be set in a class and will cause execution to halt at that point.
Create a breakpoint before starting VM and see that it resolves correctly. Create a breakpoint after starting VM and see that it resolves immediately (at least it generally will). Change breakpoint settings during an active session and ensure they take effect. Disable the breakpoint and re-enable; it should resolve again.
Set a line breakpoint at a line with no executable code. An error message should indicate that the line was not found. This means that particular source line does not have a line definition in the class.
Breakpoints support a suspend policy in which all threads, the event thread, or no threads will be suspended when the breakpoint is hit. Try the three options to make sure they work.
Start by setting a breakpoint at a point in the test code that will be executed many times. Now change the breakpoint to have a skip count greater than zero. Observe as the breakpoint is not hit the first skip-count times. This test should be done with code that prints something to the screen each time the code is executed, so that the skip test can be easily confirmed.
Start by setting a breakpoint at a point in the test code that will be executed many times. Now change the breakpoint to have an expire count greater than zero. Observe as the breakpoint stops halting execution after expire-count times. This test should be done with code that prints something to the screen each time the code is executed, so that the expire test can be easily confirmed.
Create a breakpoint at a point in the test code that will be executed several times. Have the breakpoint halt execution at least once to confirm that it works. Then change the breakpoint to be disabled and ensure that the code is not halted since the breakpoint is now disabled.
Create a breakpoint at a point in the test code that will be executed several times. Have the breakpoint halt execution at least once to confirm that it works. Then change the breakpoint's parent group to be disabled and ensure that the code is not halted since the breakpoint is now effectively disabled.
The "Default" breakpoint is special in a number of ways. First, it can never be removed. Second, it is automatically disabled when the session is started. Confirm this by starting a session, disabling the default group, finishing the session, and then starting the same session over again. The default group should be renabled again.
Breakpoints support simple conditionals based on the value of
variables. Test this by setting a breakpoint inside a
for
loop. Set the condition to be a value of the index
variable. Ensure that execution stops just the one time through the
loop when the index variable equals the condition value.
Other things to try:
Breakpoints support basic monitors, which are simply commands.
Each time the breakpoint stops, the command is executed just as if
the user entered it. Test this by supplying a monitor of
"help" when a certain breakpoint is hit. Ensure that the
output from the help
command is displayed when the
breakpoint is hit.
Other things to try:
JSwat automatically saves the defined breakpoints and breakpoint groups between invocations of the program. Use the following test scenario to confirm the proper saving of the breakpoints.