STS 68 Refactoring

Refactoring Sanity Test Specification for

Author: Jiri Prox
Version: 6.8
Last update: 2008/11/25
Introduction: This is sanity test specification for refactoring module. It covers most important test cases from refactoring testspecificatis 1,2,3,4
Comments:

Contents


Test suite: Find Usages

Purpose: To verify if this part of refactoring functionality corresponds with design and works right.
Setup: These steps are required to be possible to go through following part of the test specification.

  • Unzip a project default from default_STS_68_Refactoring.zip to some work directory.
  • Start IDE with a clean userdir.
  • Invoke File | Open Project... action.
  • Select unzipped projects default.
  • Scanning structure of project should be performed (it takes a while).
  1. Class - Usages
    1. Select org.netbeans.tests.examples.packa.Bean class in the Project view.
    2. Invoke Find Usages action from the popup menu.
    3. Select Find Usages choice and in the Find Usages ... dialog and confirm it by the Find button.
    • EXPECTED RESULT: Usages of org.netbeans.tests.examples.packa.Bean (33 occurences) should be displayed in the first line of Usages window.
    • 35 occurrences are found if 'Search in Comments' is checked.
  2. Class - All Subtypes
    1. Select org.netbeans.tests.examples.packa.Bean class in the Project view.
    2. Invoke Find Usages action from the popup menu.
    3. Select Find All Subtypes choice and Search in Comments checkbox in the Find Usages ... dialog and confirm it by the Find button.
    • EXPECTED RESULT: Usages of org.netbeans.tests.examples.packa.Bean (8 occurences)
      should be displayed in the first line of Usages window.
  3. Class - Direct Subtypes
    1. Select org.netbeans.tests.examples.packa.Bean class in the Project view.
    2. Invoke Find Usages action from the popup menu.
    3. Select Find Direct Subtypes Only choice and Search in Comments checkbox in the Find Usages ... dialog and confirm it by the Find button.
    • EXPECTED RESULT: Usages of org.netbeans.tests.examples.packa.Bean (2 occurences)
      should be displayed in the first line of Usages window.
  4. Constructor
    1. Put caret on constructor BeanB() in the org.netbeans.tests.examples.packb.BeanB class.
    2. Invoke Find Usages action from the popup menu.
    3. Select Search in Comments check box in Find Usages dialog and press Find button.
    • EXPECTED RESULT: Usages of org.netbeans.tests.examples.packb.BeanB (5 occurences)
      should be displayed in the first line of Usages window.
  5. Method - Usages
    1. Put caret over make(int, String, Bean) method in the org.netbeans.tests.examples.packc.Makable class.
    2. Invoke Find Usages action from the popup menu.
    3. Select only Find Usages checkbox and Search in Comments checkbox in the Find Usages... dialog and confirm it by Find button.
    • EXPECTED RESULT: Usages of Makable.make (4 occurences)
      should be displayed in the first line of Usages window.
  6. Method - Overriding Methods
    1. Put caret over make(int, String, Bean) in the org.netbeans.tests.examples.packc.Makable class.
    2. Invoke Find Usages action from the popup menu.
    3. Select only Find Overriding Methods checkbox and Search in Comments checkbox in the Find Usages... dialog and confirm it by Find button.
    • EXPECTED RESULT: Overriding Methods of Makable.make (5 occurences)
      should be displayed in the first line of Usages window.
  7. Method - Search from Base Class
    1. Put caret over make(int, String, Bean) in the org.netbeans.tests.examples.packb.BeanB class.
    2. Invoke Find Usages action from the popup menu.
    3. Select only Find Usages, Search from Base Class and Search in Comments checkboxies in the Find Usages... dialog and confirm it by Next button.
    • EXPECTED RESULT: Usages of Makable.make (4 occurences)
      should be displayed in the first line of Usages window.
  8. Field
    1. Put caret over refID in the org.netbeans.tests.examples.packa.Bean class.
    2. Invoke Find Usages action from the popup menu.
    3. Select Search In comments checkbox and confirm dialog by Find button.
    • EXPECTED RESULT: Usages of refID (16 occurences)
      should be displayed in the first line of Usages window.
    • EXPECTED RESULT: 13 occurrences are found if Search In comments is unselected.
  9. Java Class - String
    1. Open org.netbeans.tests.examples.packc.Makable .
    2. Put caret over String in declaration of method make(...).
    3. Invoke Find Usages action from the popup menu.
    4. Select Find Usages radio button and check that scope is set only to project default, confirm it by Find button.
    • EXPECTED RESULT: Usages of java.lang.String (39 occurences)
      should be displayed in the first line of Usages window.
    • 40 occurrences are found if 'Search in Comments' is checked.
  10. Java Class - scope
    1. Open at least one another project
    2. Open org.netbeans.tests.examples.packc.Makable
    3. Put caret over String in declaration of method make(...)
    4. Invoke Find Usages action from the popup menu.
    5. Select Find Usages radio button and check that scope is set only to all opened preject, confirm it by Find button.
    • EXPECTED RESULT: Usages of class String are found in all opened projects


Test suite: Rename

Purpose: To verify if this part of refactoring functionality corresponds with design and works right.
Setup: These steps are required to be possible to go through following part of the test specification.

  • Unzip a project default from default_STS_68_Refactoring.zip to some work directory.
  • Start IDE with a clean userdir.
  • Invoke File | Open Project... action.
  • Select unzipped projects default.
  • Scanning structure of project should be performed (it takes a while).

After each testcase use Undo from the Refactor menu to get sources to original state or perform opposite refactoring (e.g. rename it back). Try to clean & build project after each refactoring, there should not be any compilation error, unless it is explicitly written in this test specification. The number of occurrences can differ, the significant is that the application in compilable and its behavior is not changed.

  1. Package
    1. Select org.netbeans.tests.examples.packa package node in the Project view.
    2. Invoke Refactoring | Rename action from the popup menu.
    3. Fill a new package name org.netbeans.tests.examples.packarenamed in the Rename dialog, confirm this dialog by Preview button.
    4. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Rename org.netbeans.tests.examples.packa to org.netbeans.tests.examples.packarenamed (23 occurences)
      should be displayed in Refactoring window. After Do Refactoring action should be project compilable.
  2. Class
    1. Select org.netbeans.tests.examples.packa.Bean class node in the Project view.
    2. Invoke Refactoring | Rename action from the popup menu.
    3. Fill a new class name BeanRenamed and confirm it by Preview button.
    4. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Rename Bean to BeanRenamed (36 occurences)
      should be displayed in Refactoring window. After Do Refactoring action should be project compilable. 38 occurrences are updated if 'Apply rename on comments' is selected.
  3. Class - non-primary top level
    1. Put caret ower name in declaration of org.netbeans.tests.examples.packb.BeansD.BeanD class.
    2. Invoke Refactoring | Rename action from the popup menu.
    3. Fill a new class name BeanDRenamed and confirm it by Preview button.
    4. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Rename BeanD to BeanDRenamed (3 occurences)
      should be displayed in Refactoring window. After Do Refactoring action should be project compilable.
  4. Rename Method
    1. Put caret over getProtectedProperty() of the org.netbeans.tests.examples.packb.BeanA class
    2. Invoke Refactoring | Rename action from the popup menu.
    3. There should be displayed warning: There are methods in subclasses/implementors of BeanA that override or implement this method. They will also be renamed.
    4. Press Next button.
    5. Fill a new method name getProtectedPropertyRenamed and confirm this dialog.
    6. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Rename getProtectedProperty to getProtectedPropertyRenamed (14 occurences)
      should be displayed in Refactoring window. After Do Refactoring action should be project compilable.
  5. Rename Field
    1. Put caret on field protectedProperty of the org.netbeans.tests.examples.packb.BeanA class in the Project view.
    2. Invoke Refactoring | Rename action from the popup menu.
    3. Fill a new field name protectedPropertyRenamed and confirm this dialog.
    4. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Rename protectedProperty to protectedPropertyRenamed (19 occurences)
      should be displayed in Refactoring window. After Do Refactoring action should be project compilable. 24 occurrences are updated if 'Apply rename on comments' is selected.
  6. Rename Local Field
    1. Open class org.netbeans.tests.examples.packc.BeanE in the source editor.
    2. Move cursor to attribute v1 of the method public double count(double[[ | ]] v1, double[[ | ]] v2).
    3. Invoke Refactoring | Rename action from the popup menu.
    4. Fill a new field name vector1 and and confirm this dialog
    5. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Rename v1 to vector1 (9 occurences)
      should be displayed in Refactoring window. After Do Refactoring action should be project compilable.


Test suite: Move Class

Purpose: To verify if this part of refactoring functionality corresponds to design and works right.
Setup: These steps are required to be possible to go through following part of the test specification.

  • Unzip a project default from default_STS_68_Refactoring.zip to some work directory.
  • Start IDE with a clean userdir.
  • Invoke File | Open Project... action.
  • Select unzipped projects default.
  • Scanning structure of project should be performed (it takes a while).

After each refactoring is performed, call Undo from refactoring menu to get sources to original state. Check that Undo is performed correctly.

  1. Move class
    1. Select org.netbeans.tests.examples.packa.Bean class in the Project view.
    2. Invoke Refactoring | Move Class ... action from the popup menu.
    3. Select org.netbeans.tests.examples.packb in To Package combobox and confirm it by Preview button.
    4. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Move class Bean to org/netbeans/tests/examples/packb package (15 occurences)
      should be displayed in Refactoring
  2. Package private field
    1. Select org.netbeans.tests.examples.packb.BeanA class in the Project view.
    2. Invoke Refactoring | Move Class ... action from the popup menu.
    3. Problem: Class "BeanB" within the same package is using protected field "protectedProperty" of class you want to move ("BeanA"). should be displayed. Continue by Next button.
    4. Select org.netbeans.tests.examples.packa in To Package combobox and and confirm it by Preview button.
    5. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Move class org.netbeans.tests.examples.packb.BeanA to org/netbeans/tests/examples/packa package (6 occurences)
      should be displayed in Refactoring
  3. Drag and Drop
    1. Select AbstractBean and Makable in the org.netbaens.tests.examples.packc , drag them and drop into org.netbeans.tests.examples.packa.
    2. Move dialog will be displayed. List of Classes list contains both selected classes. Confirm dialog by the Preview button.
    3. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Move Classes (16 occurrences)
      should be displayed in Refactoring window. After Do Refactoring project will be compilable.


Test suite: Change Method Parameters

Purpose: To verify if this part of refactoring functionality corresponds to design and works right
Setup: These steps are required to be possible to go through following part of the test specification.

  • Unzip a project default from default_STS_68_Refactoring.zip to some work directory.
  • Start IDE with a clean userdir.
  • Invoke File | Open Project... action.
  • Select unzipped projects default.
  • Scanning structure of project should be performed (it takes a while).


  1. Constructor
    1. Put caret over constructor BeanA() from the org.netbeans.tests.examples.packb.BeanA class
    2. Invoke Refactoring | Change Method Parameters action from the popup menu.
    3. In the Change Method Parameters dialog press the Add button and fill Name, Type and Default Value for new created parameter as name , java.lang.String and "".
    4. Press Preview button.
    5. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Change parameters of BeanA constructor to public BeanA(String name) (4 occurences)
      should be displayed on the first line of Refactoring
  2. Add parameter
    1. Put caret over method abc() from the org.netbeans.tests.examples.packa.Bean class.
    2. Invoke Refactoring | Change Method Parameters action from the popup menu.
    3. In the Change Method Parameters dialog press the Add button and fill Name and Type for the new created parameter as id and int. Leave Default Value field empty.
    4. There should be displayed an error notice "Error: You have to provide default values for all new parameters." Fill Default Value as 0.
    5. Press Preview button.
    6. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Change parameters of abc method to public org.netbeans.tests.examples.packa.Bean abc(int id) (12 occurences)
      should be displayed on the first line of Refactoring
  3. Remove parameter
    1. Select method make(int index, String s, Bean bean) from the org.netbeans.tests.examples.packc.Makable class.
    2. Invoke Refactoring | Change Method Parameters action from the popup menu
    3. In the Change Method Parameters dialog select "bean" parameter and press the Remove button.
    4. Notice that Access Modifier combobox is disabled for interfaces.
    5. Press Preview button.
    6. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: Change parameters of make method to public abstract void make(int index, java.lang.String s) (10 occurences)
      should be displayed on the first line of Refactoring
  4. Parameter position
    1. Put caret over make(int index, String s, Bean bean) in the org.netbeans.tests.examples.packc.Makable class.
    2. Invoke Refactoring | Change Method Parameters action from the popup menu.
    3. In the Change Method Parameters dialog select "s" parameter and press the Move Up button.
    4. Press Preview button.
    5. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: All method call are updated, project is compilable.


Test suite: Encapsulate Fields

Purpose: To verify if this part of refactoring functionality corresponds to design and works right.
Setup: These steps are required to be possible to go through following part of the test specification.

  • Unzip a project Encapsulate from encapsulate_STS_68_Refactoring.zip to some work directory.
  • Invoke File | Open Project... action.
  • Select unzipped project.
  • Scanning structure of project should be performed (it takes a while).


  1. Encapsulate field
    1. Put caret over field field from the MainClass.
    2. Invoke Refactoring | Encapsulate Fields action from the popup menu
    3. Select creating getter and setter, press Preview button.
    4. If you agree with these changes press Do Refactoring button and changes will be performed.
    • EXPECTED RESULT: The getter/setter are generated, modifier of the field is changed to desired value (private by default) and all usages are replaced by calls of getter or setters.
  2. Change getter, setter name, modifier
    1. Put caret over field field from the MainClass.
    2. Invoke Refactoring | Encapsulate Fields action from the popup menu.
    3. Change getter/setter name and its modifier.
    4. Press Preview button.
    5. If you agree with these changes press Do Refactoring button and changes will be performed
    • EXPECTED RESULT: The getter/setter has correct name and the modifiers are as specified in dialog.
  3. Use Accessors if needed
    1. Call Encapsulate field on field x in class Access.
    2. Change visibility modifier to protected.
    3. Uncheck Use accessors even when field is visible checkbox.
    4. Press Preview and inspect proposed changens.
    5. Preform refactoring.
    • EXPECTED RESULT: Getter and setter are generated, visibility modifier is changed. Accessors are used only in class AccessB.
  4. Existing methods
    1. Call Encapsulate field on field a in class ExMethod.
    2. Keep defaults name.
    3. Perform refactoring.
    • EXPECTED RESULT: The modifier are not changed, since they already exists.


Test suite: Miscellaneous

Purpose: To verify if this part of refactoring functionality corresponds to design and works right.
Setup: These steps are required to be possible to go through following part of the test specification.

  • Unzip a project default from default_STS_68_Refactoring.zip to some work directory.
  • Start IDE with a clean userdir.
  • Invoke File | Open Project... action.
  • Select unzipped projects default.
  • Scanning structure of project should be performed (it takes a while).


  1. Undo/Redo
    1. Perform some previous testcase (rename, ...) and invoke Undo action.
    2. Verify if changes were reverted to the initial state.
    3. Invoke Redo action.
    4. Verify if changes were same like after refactoring.
    • EXPECTED RESULT: Verification was performed during testcase.
  2. Preview window
    1. Open preview for refactoring (any of the earlier described testcases).
    2. Try function of the buttons in the left part.
    3. Click on some item in the tree.
    4. Double click on some item in the tree.
    • EXPECTED RESULT: The buttons in the right has following functions:
      * Refresh refactoring data - brings back refactoring dialog, the values in the should in the state as they were when button Preview was pressed.
      * Expand/Collapse all Node - expands/collapses the tree of refactoring preview.
      * Show logical view - changes refactoring tree to show hierarchical package structure.
      * Show physical view - the tree shows only project and files where the changes will be performed.
      * Previous Occurrence, Next Occurrence - jumps to previous/next node in the refactoring tree.
      * Click on item opens and or set the preview to show related change (if available).
      * Double click shows related position in the main editor.
  3. Preview window - shortcut
    1. Open preview for refactoring (any of the earlier described testcases).
    2. Try shortcuts Ctrl-comma, Ctrl-period.
    • EXPECTED RESULT: The caret jump on next/previous item in result as when clicking on arrow button in left panel.
  4. Find usages window
    1. Close 'Usages' window.
    2. Go to Window -> Output -> Find Usages Results.
    • EXPECTED RESULT: The empty window 'Usages' is opened in output area.
  5. Refactoring preview window
    1. Close Refactoring window.
    2. Go to Window -> Output -> Refactoring Preview.
    • EXPECTED RESULT: The empty window 'Refactoring' is opened in output area.
  6. Refactoring preview window - panels
    1. Perform several find usages in a row.
    2. Right click on tab in Usages window.
    3. Try Close Tab, Close All, Close Others Tabs actions.
    • EXPECTED RESULT: The required tabs are closed.


Test suite: Introduce Method

Purpose: This Test suite is focused on common usecase of the Introduce Method refactoring.
Setup: Open project Refactoring, wait until the classpath scan ends.

  1. New method without return statement
    1. Open file packageA.ClassA.
    2. Select text between marks //1 and //2 in the method noReturn.
    3. Call Refactor -> Introduce method.
    4. Fill in method name and press OK.
    • EXPECTED RESULT: The new method is created containing the selected code.
  2. Method with return statement
    1. Open file packageA.ClassA.
    2. Select the code form mark //3 to //4.
    3. Open quick fix menu (alt-enter) and invoke Introduce method hint.
    4. Enter any name and press ok.
    • EXPECTED RESULT: New method without any parameters is created. The original place is modified that the variable c is initialized by method's call.
  3. Ending with return/break/continue
    1. Open file packageA.ClassA.
    2. Mark code between //7 and //8.
    3. Refactor -> Introduce Method.
    4. Perform refactoring.
    5. Undo changes.
    6. Try to change the continue command to break and return respectively.
    • EXPECTED RESULT: In the step 3 a new method is created. The original selection is replaced with method call and the last statement ( continue; ) stays as it is.
  4. Illegal refactoring - too many outputs
    1. Open file packageA.ClassA.
    2. Select code between //0 and //1.
    3. Call Refactor | Introduce Method.
    • EXPECTED RESULT: Error message announcing too many return variables is popped up.
  5. Illegal refactoring - selection contains return/break/continue
    1. Open file packageA.ClassA.
    2. Mark code between //6 and //7.
    3. Refactor -> Introduce Method.
    4. Try to change the continue command to break and return respectively and repeat steps 2) and 3).
    5. Comment out the line s = s+"--, "; and try again.
    • EXPECTED RESULT: The error message "Too many output parameters" is displayed at first. After commenting out the specified line, the refactoring can be performed and semantic of the code is not changed.
  6. Static modifier
    1. Open file packageA.ClassA.
    2. Select the code form mark //11 to //12.
    3. Call Introduce Method.
    • EXPECTED RESULT: The created method is static.


Test suite: Introduce Field

Purpose: This Test suite covers introduce field transformation.
Setup: Open project Refactoring, wait until the classpath scan ends. After each refactoring press Undo to get sources to original state.

  1. Constant expression
    1. Open file packageE.ClassA.
    2. Select text "3+3".
    3. Call Refactor -> Introduce Field.
    4. Fill in field name, set access modifier to private, check Replace all occurrences(4) and uncheck Declare Final, initialize in constructor.
    5. Press OK.
    • EXPECTED RESULT: Radio button Initialize in current method is disabled. When performed all occurrence of expression 3+3 are replaced by field of given name. Constructor is added, it it's body the new filed is initialized by selected expression.
  2. Constant expression, initialize in current method
    1. Open file packageE.ClassA.
    2. Select text "3+3" in the first method.
    3. Call Refactor -> Introduce Field.
    4. Fill in field name, uncheck Replace all occurrences(4) and uncheck Declare Final, initialize in current method.
    5. Press OK.
    • EXPECTED RESULT: When the dialog is opened, the last values should be preset. When unchecking Declare final the radio button Initialize in current method is enabled. After confirmation the new field of given name is created, it is initialized in current method and selected expression is replaced by this new field.
  3. Final field, initialize in field
    1. Open file packageE.ClassA.
    2. Select text "Text" in the "method method3()".
    3. Use Alt-Enter to show list of possible hints and select.
    4. Fillin field name, initialize in field, check Declare final, change access modifier to package private.
    5. Press OK
    • EXPECTED RESULT: The Replace All Occurrences are disabled (there is only one occurrence), when selecting Initialize in field, the declare final is enabled (if it was initially disabled). After confirmation the final package private field is created and it is used in the original place. Nre field is static.


Test suite: Introduce Constant

Purpose: This Test suite covers introduce constant transformation.
Setup: Open project Refactoring, wait until the classpath scan ends. After each refactoring press Undo to get sources to original state.

  1. Introduce constant - replace all occurrences
    1. Open file packageE.ClassB.
    2. Select "Text".
    3. Call Introduce Constant from menu.
    4. Fill in a new name, check Replace All Occurrence.
    5. Press OK.
    • EXPECTED RESULT: The Declare final checkbox is always checked and disabled. After confirmation a new constant of given name is introduced and all occurrences of "Text" are replace by the new constant.
  2. Introduce constant - replace one occurrence
    1. Open file packageE.ClassB..
    2. Select constant 3 in the method statMethod().
    3. Fill in a new name and uncheck Replace all occurrence.
    4. Press OK.
    • EXPECTED RESULT: The new constant is declared as static. Only selected occurrence of constant 3 is replaced by the new constant.


Test suite: Introduce Variable

Purpose: This Test suite covers introduce variable refactoring.
Setup: Open project Refactoring, wait until the classpath scan ends. After each refactoring press Undo to get sources to original state.

  1. Introduce variable - all occurrences
    1. Open file packageE.ClassC.
    2. Select "3.3" double literal.
    3. Call Introduce Variable from the Refactor menu.
    4. Fill in new name, check Replace all occurrences and uncheck Declare final.
    5. Press OK.
    • EXPECTED RESULT: New local variable is introduced and initialized to selected valued. All occurrences of selected expression are replace by the new variable.
  2. Introduce variable - declare final
    1. Open file packageE.ClassC.
    2. Select "3.3" and from hint list select introduce variable.
    3. Enter new name, check Declare Final and uncheck Replace all occurrences
    • EXPECTED RESULT: Final variable is created. Only selected occurrence is replaced.


Test suite: Extract Interface

Purpose: This suite tests Extract Interface refactoring in several common usecases.
Setup: Open project Refactoring and wait until the classpath scan ends.

  1. Simple case
    1. Open file packageB.ClassA.
    2. Go to editor.
    3. Call Refactor -> Extract Interface from the main menu.
    4. Fill in the interface name.
    5. Select some members to be extracted and click on Preview.
    6. Do Refactor.
    • EXPECTED RESULT: Public static final fields, public methods and implemented interfaces are listed in the Extract Interface dialog. The preview shows all proposed changes. After refactoring is performed the new interface is created and all selected elements are moved/copied to it.
  2. Extract from interface and enum
    1. Open file packageB.InterfaceA.
    2. Call Extract Interface on it.
    3. Enter new interface name and preform refactoring.
    4. Undo changes.
    5. Open file packageB.Enumeration.
    6. Call Extract Interface on it.
    7. Enter new interface name and preform refactoring.
    • EXPECTED RESULT:
      * Both refactorings are OK,
      * in the Extract Interface dialogs, there were displayed proper members,
      * new interfaces are created.
  3. Extract from generic class
    1. Open file packageB.ClassB.
    2. Call Extract Interface on it.
    3. Select provided element.
    4. Press preview.
    5. Inspect proposed changes.
    6. Confirm refactoring.
    • EXPECTED RESULT: The new generic interface is created and implements statement is correctly added to the original class.


Test suite: Extract Super Class

Purpose: This test suit concerns Extract Super Class refactorings.
Setup: Open project Refactoring, wait until the classpath scan ends.

  1. Basic case
    1. Open packageC.ClassA.
    2. Call Refactor -> Extract Super Class.
    3. Select some items from 'Members to Extract' table and press Preview.
    4. Inspect the contents of the preview window.
    5. Click to refresh button.
    6. Select different items from 'Members to Extract' table and confirm by clicking on Preview button.
    7. Inspect new contents of preview window and cancel refactoring.
    8. Call again Refactor -> Extract Super Class.
    9. Select some items from Members to extract table and confirm dialog.
    10. Confirm refactoring.
    • EXPECTED RESULT: In refactoring dialog there are listed all elements form class ClassA which can be extracted to super class. The preview window always contains planned changes reflecting the values entered in the dialog. After canceling operation no changes are made to the code. After last step the refactoring is performed, new class is created and the original class is modified.
  2. Making methods abstract
    1. Open packageC.ClassB.
    2. Call Refactor -> Extract Super Class.
    3. In the 'Members to Extract' table select the method method() to be extracted and check Make abstract.
    4. Confirm dialog.
    5. Confirm whole refactoring if preview window is opened.
    • EXPECTED RESULT: The new abstract super class is created with abstract method method. In the original class, the name of the new super class is added to extends statement and the code of the extracted method is not changed.
  3. Refactoring 1.5 features
    1. Open file packageC.classE.
    2. Invoke Refactor -> Extract Super Class.
    3. Select method method() to be extracted.
    4. Perform refactoring.
    • EXPECTED RESULT: The refactoring is performed correctly. New generic super class is created, its name (without generic type) is added to extends statement. The both classes can be compiled.


Test suite: Safely Delete

Purpose: This suite tests common usage of Safe Delete refactoring.
Setup: Open project Refactoring, wait until the classpath scan ends.

  1. Deleting used elements
    1. Open packageD.ClassB.
    2. Step by step keep placing cursor on every word in the source code and try Safely delete (for fully qualified names, put cursor on every part separated by '.').
    3. Go to project view and call Refactor -> Safe Delete from the context menu on the ClassB.java node.
    • EXPECTED RESULT: Every time the refactoring dialog is opened it contains information about the element which is going to be deleted or a error message the safe delete isn't supported for the appropriate node. When continuing in the refactoring the usages are found.
  2. Deleting unused elements
    1. Delete class User.java.
    2. Repeat last test case.
    • EXPECTED RESULT: Now, no usages are found during refactoring and all possible elements are deleted.


Test suite: Pull Up

Purpose: Pull Up moves elements of the class to the super class. Moved elements can be fields, methods, inner classes and implemented interfaces. When moving private elements its modifier must be changed to protected in order to be accessible from original class.
Setup: Unzip and open project PushPull.

  1. Pull Up basic
    1. Invoke Refactor | Pull Up for VIPCustomer class.
    2. Select class Customer as a target.
    3. Select all elements and press Preview.
    4. Review all changes and click Do Refactoring.
    • EXPECTED RESULT: In the dialog, there are listed all pull-able elements. Methods have extra checkbox Make abstract. After confirming action, all elements are moved to the superclass (there is error in RegularCustomer class after the refactoring - invalid method overriding).
  2. Pull Up and make abstract
    1. Invoke Refactor | Pull Up for VIPCustomer class.
    2. Check methods and check Make Abstract checkbox.
    3. Select Customer as a target.
    4. Click Preview, review all changes and click Do Refactoring.
    • EXPECTED RESULT: Empty bodies of selected methods must be created in class Customer, VIPCustomer class must stay unchanged (there is error, since the other subclass of Customer does not implement pulled methods).
  3. Pull Up - no supertype
    1. Invoke Refactor | Pull Up for ClassWithNoSupertype class
    • EXPECTED RESULT: Error messages "Cannot pull up any members. The selected type has no supertypes in the currently opened projects" is shown, action cannot continue.
  4. Pull Up to interface
    1. Invoke Refactor | Pull Up for ImplementsIface class.
    2. Select all methods.
    3. Click Preview, review all changes and click Do Refactoring.
    • EXPECTED RESULT: Selected elements are moved. In the preview methods elements has checked and disabled checkbox Make abstract.


Test suite: Push Down

Purpose: Push down moves selected elements lower to the subclasses. If the actual class has more subclasses the elements are propagated to all of them. All elements such fields, methods, inner classes and implemented interfaces can be pulled down, regardless of their modificators.
Setup: Unzip and open project PushPull.

  1. Push Down basic
    1. Invoke Refactor | Push Down for SuperBaseClass class
    2. Select all elements and press Preview.
    3. Review all changes and click Do Refactoring.
    • EXPECTED RESULT: All elements should be moved to all subclasses. Note that there is warning about field fieldString, which already exists in one of the subclasses. When refactoring is performed, the declaration of fieldString is doubled in one of the subclasses. Necessary imports are added to all subclasses.
  2. Push Down and keep abstract
    1. Invoke Refactor | Push Down for MySuperClass class.
    2. Select methods getX and setX and check keep abstract for both of them (push down the field x as well).
    3. Click Preview and click Do Refactoring.
    • EXPECTED RESULT: Both methods are moved to subclass, in the current class abstract methods are created instead of them. Note that modifier of x changed from private to protected.
  3. Push Down from interface
    1. Invoke Refactor | Push Down for SuperInterface class.
    2. Select all element press Preview.
    3. Review all changes and click Do Refactoring.
    • EXPECTED RESULT: All elements are moved to sub interface.


Test suite: Inner to Outer

Purpose: This type of refactoring moves inner class one level up. If it was originally in the top level class it is moved to separate file. The problem with accessing elements in the original outer class is solved by adding parameter to constructor passing instance of outer class.
Setup: Unzip and open project ConvertClasses.

  1. Inner to Outer - basic
    1. Put caret in the body of class Inner1 located in OuterClass.
    2. Call Move Inner to Outer Level.
    3. In the dialog change Class Name to Rename, Field Name to orig.
    4. Click Preview, inspect all changes and confirm by Do Refactoring.
    • EXPECTED RESULT: New file with class Renamed is created. Its constructor has one parameter orig of type OuterClass. The occurrences of Inner1 is replaced with the new name. The modifiers of field and privMethod are changed to package public. The getInner() method of the original outer class contains return new Renamed(this);. Class User has correct reference to new class.
  2. Inner to Outer - static class
    1. Call Move Inner to Outer Level for class Inner2 located in OuterClass.
    2. Keep all options as default.
    3. Click Preview, review all changes and confirm by Do Refactoring.
    • EXPECTED RESULT: The class is moved into new file as top-level class. Class User has correct reference to moved class. Filed referring to original class is not generated.
  3. Inner to Outer - constructors
    1. Call Move Inner to Outer Level for class InnerClass located in Wrapper class.
    2. In the dialog, leave all options as default.
    3. Click Preview, review all changes and confirm by Do Refactoring.
    • EXPECTED RESULT: New separate file with class Inner is created. All constructors are updated to accept reference to outer class as additional parameter.


Test suite: Anonymous to Inner

Purpose: This refactoring converts selected anonymous class to regular inner class.
Comments: This is implemented in Java/hints module.
Setup: Unzip and open project ConvertClasses.

  1. Anon to Inner - basic
    1. Open ClassA in editor and call refactoring for its anonymous class.
    2. Type new name.
    3. Use editor undo for taking the changes back.
    • EXPECTED RESULT: New inner class is created. It's name is derived from original name by appending "Impl", the body of anonymous class is move to the newly introduced class and at original place, there is call of its constructor. The instant-rename for name of new class is on, so when the user is typing the new class is beeing renamed. Enter ends the renaming. Undo reverts all changes.


Test suite: Use Supertype

Purpose: This kind of refactoring tries to use selected supertype where possible, e.g. changes the type of variable to the supertype if it doesn't use methods or fields of any its subtype.
Setup: Unzip and open project ConvertClasses.

  1. Use Supertype - basic
    1. Call Use Supertype Where Possible for class Sub.
    2. Select java.lang.Object from the list and check Preview All Changes.
    3. Click Preview, review all changes and confirm by Do Refactoring.
    • EXPECTED RESULT: Occurrence is found, check the class User, there should be s6 and s7 retyped to Object.


Test suite: Call Hierarchy

Setup:
- Start IDE with a fresh userdir. Download and unzip projects File:SampleProjects.zip CallHierarchy and CallHierarchyDep.
- Turn on line numbers by View>Show Line Numbers from the main menu, just to make work with this test specification more fluent.
- Open a sample project CallHierarchy.

  1. Callers hierarchy
    1. Open file Main.java in editor .
    2. Right-click the method "CapFirstLetter" on line 29 and invoke Call Hierarchy from popup menu.
    3. Note: You can alternatively place a caret on "CapFirstLetter" (like "CapF|irstLetter") and invoke Window > Output > Call Hierarchy from the main menu - we will use popup menu in this test specification, but you may try to vary both methods.
  2. Callers hierarchy - Show lines with method calls
    1. Click the sub-node main(String[[ | ]] args)::callhierarchy.Main in the tree.
  3. "Callees" hierarchy
    1. Click Show Hierarchy of Callees toggle button in the "Java Call Hierarchy" view.
  4. Call Hierarchy - Recursive calls
    1. Open NewClassRecursive.java in the editor.
    2. Invoke Call Hierarchy from the popup menu above the "fib" method on line 14.
    • EXPECTED RESULT: Call Hierarchy for the current method is shown. Tree contains only one sub-node, this sub-node has a little badge suggesting recursive call. Results are the same for callers and callees in this case, there are two lines with usage displayed when you click the caller's/callee's node.
      http://wiki.netbeans.org/attach/TS_65_CallHierarchy/testcase5.png
  5. Call Hierarchy - Go to source (First occurrence)
    1. Open NewClassRecursive.java in the editor .
    2. Invoke Call Hierarchy from the popup menu above the "fib" method on line 14.
    3. Double-click the only sub-node in the tree (the one with a badge indicating recursive call), or invoke Go to source from the popup menu above this sub-node.
    • EXPECTED RESULT: You are navigated to the first call within the method fib.
  6. Call Hierarchy - Expanding nodes
    1. Open NewClassCycle1.java in editor.
    2. Invoke Call Hierarchy from the popup menu above the "gFunct" method on line 14 (you can view callers or callees).
    3. Expand all nodes in the tree.
    4. Open main.java in the editor.
    5. Invoke Call Hierarchy from the popup menu above the "CapFirstLetterOfEachWord" method on line 45.
    6. Click Show Hierarchy of Callers to ensure you are viewing callers of "CapFirstLetterOfEachWord" method.
    7. Expand all nodes in the tree again.


Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo