|[jdt-dev] Input for JDTTest Plan|
Enclosed my suggestions what to test during the upcoming test phase: GTK (JDT-UI part): - test layout and size of dialogs, preference pages, property pages and wizards. - specially look at compare where we do some tricks with hiding scrollbars etc. - speed of editor (lots of custom drawing) - flashing of view in refresh (redraw on/off setting) - adding of methods and reconcile (outliner, packages view). Refactoring: - refactor read-only files - use pessimistic team provider (Kai-Uwe or Adam know where to get it) together with refactoring. E.g refactor file that are not checked out. - Test Self Encapsulate Field and Surround with try/catch... (new code) - Test Rename & Move. Especially corner cases that aren't allowed, since precondition checking got recoded for these refactorings. - Test Refactoring with auto-build on and unsaved files. There should only be an auto-build when pressing finish or cancel, not after saving files. - Test Preview page of refactoring wizard: o tool bar buttons (arrow up, down) o uncheck items (compare adjusts) o perform refactoring with unchecked items - Undo/Redo (got partly recoded for M6) o perform undo/redo o perform undo/redo with unsaved files not affected by the undo o perform undo/redo with unsaved files effected by the undo. o perform build after refactoring and ensure that undo is still possible. o change Java element: ensure that undo stack gets flushed. Search: - test replace in Text/File search (available via context menu on search result). Menus/icons: - have an eye on enabled and disabled menu items in the global tool bar (e.g. right enablement state) - context menus should not contain disabled menu items except cut, copy paste. - have an eye on icons (we got new icons this week). Leak scenarios: - Rename and Move refactorings create a lot of temporary working copies. Make sure that they get garbage collected (destroyed). - most of our global actions are now a selection change listener. Make sure that we don't leak any view when closing it because an action is still registered somewhere as a selection listener. Performace/Memory scenarios: - Rename a class that has a lot of references (for example IResource form org.eclipse.core.resources). - Push up a field from a class that has a lot of subclasses (for example push up a field of an action into the Action class.
Back to the top