Proposal: Better Debugging (2006)
Last updated at 10:12 am UTC on 10 October 2019
Improving Debugging in Smalltalk
Ashley George Taylor
CS8503 Fall '98, Prof. Guzdial
In an earlier study [TayGuz97], we found that students find the Smalltalk Debugger difficult to understand and use because:
- They do not understand the interface
- They do not understand the OOL execution model
- Its execution pattern is hard to follow
The debugger does not support the formation of a mental model of execution of an OOL for novices. We propose to design a debugger which makes the Smalltalk execution model explicit and visual.
The main aspects of the Smalltalk execution model are:
- Sequential execution of statements
- Message execution order
- Message sending
- Method lookup
- Object return/result from message
- Object creation and deletion
- Variable classification: instance, temporary, class
- Class method vs. Object method distinction
We propose a Smalltalk tracing tool/debugger for novices which uses some aspects of the existing debugger, but has the following features:
An 'environment' is similar to the current debugger window, but it does not have a call stack. Each variable category is clearly labeled and displayed above the code pane. All object values are updated live, and they flash when they change to draw the users attention. There is a special slot for the object returned as the result of the current message. The parameters of the current message are displayed as well. This is important in cases where the parameter objects are not among the named variables in an environment, i.e. they are the result of other messages.
Initially, the environment for the code selected in the Proposal: Better Debugging (2006)/print it is displayed. The first message is highlighted. The user can select step or send.
The step button highlights each message (which may be part of another message) in the correct order, as in the current debugger.
The Send button spawns an environment to the right of the current one. The method lookup is shown as a hierarchical list of classes similar to the list of parent directories show in a file open/save box. Changes in the new environment which affect objects in a previous environment will be reflected in the object display of the previous environment. This gives the user a view of all live objects, and a full view of execution in action.
However, there is a display space problem which could be addressed by panning or sideways scrolling, or window tiling. I propose to develop and test a prototype of this debugger next quarter.
Ideas were drawn from [Ward86], and Javation by IBM (can?t find a reference so far - saw it at a talk last year)
Essentially, testing is methodical checking to try to determine if code works correctly, actively looking for bugs rather than passively running into and reacting to them.
A simple scheme which students could use is testing each class they write as a unit. However. Some classes depend on each other, so a dependency order should be established, and classes should be tested from the bottom of the dependency tree upwards. There are cases where a class needs to be tested before one of its dependent classes is written. In this case a stub class can be written which implements dummy versions of the required methods. In cases where classes are co-dependent, a stub class will also be needed.
A test plan should be written for each class which, at a minimum, sends messages with inputs just in and outside the permitted range. This could be saved as a class method. A testing tool or debugger can be used with a test method to examine values in a more orderly fashion.
Related to debugging, Bob Arning has created the SyntaxMorph tool, which includes a graphical view of the Smalltalk syntax. This includes the text pane of the debugger, and it is possible to check the values of variables directly in the source code by passing the mouse over them. See BobArning's page for details.