EDT:Debug Regression Testing

The following test scenarios should be run each release.

Common scenarios to be run as part of each of the other sections

Stepping through statements when suspended  

• Step into
• Step over
• Step return

Run to line:

• "Ctrl + r" with the cursor on the target line
• Right-click in the editor and select "Run to Line" with the cursor on the target line

Breakpoints

• Can be set by double-clicking the editor's left margin, or right-click the margin to add
• Can enable/disable breakpoints, changes take immediate effect

Variables view

• All variables in scope are listed
• Value and type for each variable looks correct
• Values can NOT be changed during debugging (future feature)
• Test all the supported types (primitives, arrays, records, dictionaries, delegates, handler fields, etc...)

Debug view

• When suspended, the function stack looks correct
• Stack frames have correct names and line numbers
• Clicking on frames updates the variables view to show that frame's variables, and selects the appropraite line in the editor

Batch programs (Java)

Launched by right-clicking a main program source file > Debug As > EGL Java Main Application

Drop to frame

• Pops off any frames above the target frame
• Repositions to the beginning of the function
• Note: Disabled on frames that are directly above native methods, or when a native method is above the target frame (JDT restriction)

Stepping

• Can step into Java code, such as a user-written external type.

Hot code replace

• Limited support from JDT, no EGL-specific support
• Small changes might work, like changing logic
• Structural changes might not work, like adding new functions or global variables

Type filters

• When enabled, certain types are automatically run instead of suspending inside them
• Located in Preferences > EGL > Debug > Java Debugging
• Can disable filters as a whole
• Can disable specific filters
• Can change step type ("step into" will step "through" the code until it reaches an unfiltered type, while "step return" runs much faster)
• Can define your own custom filters at Preferences > Java > Debug > Step Filtering
• Quick toggle located in Debug view's toolbar menu (click the downward triangle to the right of the stepping buttons, and expand the "EGL" submenu)

Services (Java) 

To debug a service you will need to write a client that invokes it (see the "Rich UI" section below). You cannot "step into" the service invocation from RUI, so put a breakpoint in the service function. To have RUI run the service in debug mode, either use dedicated services or a workspace:// URI for a REST service.

Everything from the "Batch programs" section above is applicable to services.

Note: You will not be able to drop to the bottom frame because it always sits on top of a native method.

More extensive testing of the test server itself will be handled by the test server regression test wiki page

Rich UI Handlers (JavaScript)

Launched by:

• Right-clicking a Rich UI Handler source file > Debug As > EGL Rich UI Application
• Selecting a Rich UI Handler file (in Project Explorer or making its editor active) and clicking the Debug icon in the main toolbar

Drop to frame

• Not supported, button should be disabled

Stepping

• Can NOT step into non-generated JavaScript code, such as user-written external types.

Hot code replace

• Not supported, changing source does not affect active debug sessions

Service calls

• Using dedicated services will cause the test server to run the service (where breakpoints can be set in the service)
• Using a workspace:// URI for a REST service will also cause the test server to run the service
• Using any other URI like http:// for a REST service will NOT cause the test server to run the service, and the deployed service will instead be invoked
• Using the Visual Editor's Preview pane will follow the same rules as the Rich UI debugger for determining whether the test server is used for a service call