EDT:Debug Regression Testing
From Eclipsepedia
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