house fly

JSwat Project

Testing Breakpoints


Breakpoints Manager Dialog

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.

Breakpoints list

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.

New Breakpoint...

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.

New Group...

Presents a dialog asking the user for a breakpoint group name and a select box to choose the group's parent group.

Properties...

Presents a dialog showing the selected breakpoints properties.

Disable

Disables the selected breakpoint or breakpoint group.

Enable

Enables the selected breakpoint or breakpoint group.

Remove

Removes the selected breakpoint or breakpoint group.

Setting Breakpoints

This section is to confirm that breakpoints can be set in a class and will cause execution to halt at that point.

When to Set

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.

Non-code lines

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.

Suspend policy

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.

Skipping

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.

Expiration

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.

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 to be disabled and ensure that the code is not halted since the breakpoint is now disabled.

Disabled by group

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.

Default group auto-enables

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.

Conditions

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:

Monitors

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:

Saving Breakpoints

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.

  1. Set some breakpoints in the debuggee VM.
  2. Close the debuggee VM and close JSwat.
  3. Restart JSwat and confirm the breakpoints are still there.


Back