RefactorTSBoostAIO

Refactoring Test Specification Boost All In One

Author: Tomáš Tököly
Version: 7.0.1
Last update: 2011/07/19
Introduction: This page contains necessary information to go trough Refactoring TS extracted from all Refactoring TS (TS_60_Refactoring, TS_60_Refactoring2, TS_60_Refactoring3, TS_65_CallHierarchy).
Form of this TS should boost the entire process of testing.
Comments:

Contents


Required projects: default, Encapsulate, default2, Refactoring, PushPull, ConvertClasses, CallHierarchy+CallHierarchyDep

TS 60 Refactoring

Find Usages

Original Test Specification: TS_60_Refactoring
Project: default

  1. Class - Usages
    1. packa.Bean
    2. Find Usages - Find Usages
    • EXPECTED RESULT: 33/35 occurrences
  2. Class - All Subtypes
    1. packa.Bean
    2. Find Usages - Find All Subtypes + Search in Comments
    • EXPECTED RESULT: 8/8 occurrences
  3. Class - Direct Subtypes
    1. packa.Bean
    2. Find Usages - Find Direct Subtypes Only + Search in Comments
    • EXPECTED RESULT: 2/2 occurrences
  4. Interface - Usages
    1. packc.Makable
    2. Find Usages - Find Usages
    • EXPECTED RESULT: 17/18 occurrences
  5. Interface - All Subtypes
    1. packc.Makable
    2. Find Usages - Find All Subtypes + Search in Comments
    • EXPECTED RESULT: 7/7 occurrences
  6. Interface - Direct Subtypes
    1. packc.Makable
    2. Find Usages - Find Direct Subtypes Only + Search in Comments
    • EXPECTED RESULT: 3/3 occurrences
  7. Constructor
    1. Constructor BeanB() in the packb.BeanB
    2. Find Usages - Find Usages + Search in Comments
    • EXPECTED RESULT: 5/5 occurrences
  8. Method - Usages
    1. Method make(int, String, Bean) in the packc.Makable
    2. Find Usages - Find Usages + Search in Comments
    • EXPECTED RESULT: 4/4 occurrences
  9. Method - Overriding Methods
    1. Method make(int, String, Bean) in the packc.Makable
    2. Find Usages - Find Overriding Methods + Search in Comments
    • EXPECTED RESULT: 5/5 occurrences
  10. Method - Search from Base Class
    1. Method make(int, String, Bean) in the packb.BeanB
    2. Find Usages - Find Usages + Search from Base Class + Search in Comments
    • EXPECTED RESULT: 4/4 occurrences
  11. Field
    1. Field refID in the packa.Bean
    2. Find Usages - Find Usages + Search In comments
    • EXPECTED RESULT: 13/16 occurrences
  12. Java Class - String
    1. Open packc.Makable
    2. Select String in declaration of method make(...)
    3. Find Usages - Find Usages + scope set only to project default
    • EXPECTED RESULT: 39/40 occurrences
  13. Java Class - scope
    1. Open at least one another project
    2. Open packc.Makable
    3. Select String in declaration of method make(...)
    4. Find Usages - Find Usages + scope set only to all opened projects
    • EXPECTED RESULT: 39+/40+ occurrences


Rename

Original Test Specification: TS_60_Refactoring
Project: default

  1. Package
    1. packa
    2. Rename - packarenamed
    • EXPECTED RESULT: 23/23 occurrences
  2. Package in Files view
    1. Select default/src/org
    2. Click to the node (to activate its inplace rename)
    3. Rename - com
    • EXPECTED RESULT: 51/51 occurrences
  3. Class
    1. packa.Bean
    2. Rename - BeanRenamed
    • EXPECTED RESULT: 36/38 occurrences
  4. Class - non-primary top level
    1. packb.BeansD.BeanD
    2. Rename - BeanDRenamed
    • EXPECTED RESULT: 4/4 (5?) occurrences
  5. Class - inline
    1. Select packa.Bean
    2. Click to the node (to activate its inplace rename)
    3. Rename - BeanRenamed
    • EXPECTED RESULT: 36/38 occurrences
  6. Interface
    1. Select packc.Makable
    2. Rename - MakableRenamed
    • EXPECTED RESULT: 19/20 occurrences
  7. Rename Method
    1. Select getProtectedProperty() of the packb.BeanA
    2. Rename - getProtectedPropertyRenamed
    3. There should be displayed warning: There are methods in subclasses/implementors of org.netbeans.tests.examples.packb.BeanA that override or implement this method. They will also be renamed.
    • EXPECTED RESULT: 14/14 occurrences
  8. Rename Field
    1. Field protectedProperty of the packb.BeanA
    2. Rename - protectedPropertyRenamed
    • EXPECTED RESULT: 19/24 occurrences
  9. Rename Local Field
    1. Open packc.BeanE
    2. Select v1 of the method public double count(double[[ | ]] v1, double[[ | ]] v2).
    3. Rename - vector1
    • EXPECTED RESULT: 9/9 occurrences


Move Class

Original Test Specification: TS_60_Refactoring
Project: default

  1. Move class
    1. packa.Bean
    2. Move Class - packb
    • EXPECTED RESULT: 15 occurrences, project should be compilable.
  2. Package private field
    1. packb.BeanA
    2. Move Class - packa
    3. Problem: Class "BeanB" within the same package is using protected field "protectedProperty" of class you want to move ("BeanA"). should be displayed.
    • EXPECTED RESULT: 6 occurrences, project will not be compilable because of using of package private field protectedProperty by classes in packb
  3. Default package
    1. packb.BeanB
    2. Move Class - <default package>
    3. Problem: Class you want to move ("BeanB") is using protected field "protectedProperty" of class "BeanA" within the same package. should be displayed.
    4. Problem: If the class is moved to the default package, classes in other packages will not be able to import the moved class. should be displayed.
    • EXPECTED RESULT: 2 occurrences, project will not be compilable because of using of package private field protectedProperty by classes in packb
  4. Drag and Drop
    1. Select AbstractBean and Makable, drag them and drop into packa
    2. List of Classes list contains both selected classes.
    • EXPECTED RESULT: 16 occurrences, project should be compilable
  5. To Test Packages
    1. Files view - add test/org/netbeans/tests folder into root folder of default project
    2. Select packc.BeanE in Projects view
    3. Move - Test Packages in Location combobox, org.netbeans.tests in To Package combobox
    • EXPECTED RESULT: 2 occurrences, project should be compilable


Change Method Parameters

Original Test Specification: TS_60_Refactoring
Project: default

  1. Constructor
    1. Select BeanA() from the packb.BeanA
    2. Change Method Parameters - Add + Name/Type/Default Value = name/java.lang.String/""
    • EXPECTED RESULT: 4 occurrences. All occurrences of this constructor should be changed to BeanA("")
  2. Add parameter
    1. Select abc() from the packa.Bean
    2. Change Method Parameters - Add + Name/Type/Default Value = id/int/leave empty
    3. "Error: You have to provide default values for all new parameters.", set Default Value as 0
    • EXPECTED RESULT: 12 occurrences. All occurrences of this method should be changed to abc(0)
  3. Remove parameter
    1. Select method make(int index, String s, Bean bean) from the packc.Makable
    2. Change Method Parameters - Remove "bean" parameter
    3. Notice that Access Modifier combobox is disabled for interfaces
    • EXPECTED RESULT: 10 occurrences
  4. Visibility Modifier
    1. Select abc() from the packa.Bean
    2. Change Method Parameters - change Access Modifier to protected
    • EXPECTED RESULT: 4 occurrences
  5. Parameter position
    1. Select make(int index, String s, Bean bean) in the packc.Makable
    2. Change Method Parameters - Move Up "s" parameter
    • EXPECTED RESULT: 24 occurrences. All method call are updated, project should be compilable
  6. Vararg
    1. Select make(int index, String s, Bean bean) in the packc.Makable
    2. Change Method Parameters - Add + Name/Type/Default Value = any/int.../1,2,3
    3. Try to move it to the different position than last
    • EXPECTED RESULT: 10 occurrences


Encapsulate Fields

Original Test Specification: TS_60_Refactoring
Project: Encapsulate

  1. Encapsulate field
    1. Select field from the MainClass
    2. Encapsulate Fields - create getter and setter
    • 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. Select field from the MainClass
    2. Encapsulate Fields - change getter/setter name and its modifier
    • EXPECTED RESULT: The getter/setter has correct name and the modifiers are as specified in dialog
  3. Use Accessors if needed
    1. Select x from the Access
    2. Encapsulate Fields - change visibility modifier to protected, uncheck "Use accessors even when field is visible"
    • EXPECTED RESULT: Getter and setter are generated, visibility modifier is changed. Accessors are used only in class AccessB
  4. Usage in constructor
    1. Select y from the Ctor
    2. Encapsulate Fields - set visibility modifier to private, accessors visibility to public, select "Use accessors even when field is visible"
    • EXPECTED RESULT: Warning about usage in constructor is displayed
  5. Nothing to encapsulate
    1. EmptyClass
    2. Encapsulate Fields
    • EXPECTED RESULT: Dialog stating that EmptyClass has no fields is shown
  6. Existing methods
    1. Select field from the ExMethod
    2. Encapsulate Fields - keep default name
    • EXPECTED RESULT: The modifier are not changed, since they already exists


Miscellaneous

Original Test Specification: TS_60_Refactoring
Project: default

  1. Undo/Redo
    1. Repeat some testcase and check Undo/Redo action
    • EXPECTED RESULT: Everything is alright
  2. Same name in two projects
    1. Create JavaApplication1 and JavaApplication2; with a main class Main in the package abc
    2. Create a new class Alfa in the package abc for JavaApplication1 project
    3. Create a new class Beta in the package abc for JavaApplication2 project
    4. Rename - abc.Beta to Alfa
    • EXPECTED RESULT: Class Beta from JavaApplication2 project should be renamed to Alfa
  3. 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
    5. Try shortcuts Ctrl-comma, Ctrl-period
    • 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, Ctrl-comma, Ctrl-period - 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
    1. Open preview for any rename refactoring
    2. Uncheck several refactoring elements in the refactoring tree
    • EXPECTED RESULT: The unselected changes are not performed - not shown in preview and not performed in the code itself
  1. Concurrent modification
    1. packa.Bean
    2. Rename - enter new name and press Preview
    3. While preview is opened change significantly class Bean
    • EXPECTED RESULT: The preview shows gray label Rename ..... NEEDS REFRESH and the Do Refactoring button is disabled
  2. Output Windows
    1. Close 'Usages' and 'Refactoring' window
    2. Go to Window -> Output -> Find Usages Results + Refactoring Preview
    • EXPECTED RESULT: The empty window 'Usages' and 'Refactoring' is opened in output area
  3. Refactoring preview window - panels
    1. Perform several find usages in a row
    2. Try 'Close Tab', 'Close All', 'Close Others Tabs' actions
    • EXPECTED RESULT: The required tabs are closed


JDK 1.5 Refactoring

Original Test Specification: TS_60_Refactoring
Project: default2

  1. Refactoring 1.5 - Find Usages
    1. abc.A
    2. Find Usages - Find Usages
    • EXPECTED RESULT: 17/22 occurrences
  2. Refactoring 1.5 - Find Usages - Context
    1. Open abc.def.DAnnotType
    2. Select X of En in default value of member coord
    3. Find Usages - Find Usages + Search in Comments
    4. Find Usages dialog should contain title: "Find X of class En":.
    • EXPECTED RESULT: 4/4 occurrences
  3. Refactoring 1.5 - Rename Class
    1. abc.A
    2. Rename to TestClassName
    • EXPECTED RESULT: 22/27 occurrences
  4. Refactoring 1.5 - Rename Generics
    1. Open abc.A
    2. Select T in the class declaration
    3. Rename to X
    • EXPECTED RESULT: 10/10 occurrences
  5. Refactoring 1.5 - Rename Enumeration
    1. abc.En
    2. Rename to TestEnumeration
    • EXPECTED RESULT: 22/25 occurrences
  6. Refactoring 1.5 - Rename Enumeration Constant
    1. Select constant X in abc.En
    2. Rename to W Apply Rename in Comments
    • EXPECTED RESULT: 5/5 occurrences
  7. Refactoring 1.5 - Rename Field
    1. Select field list in abc.A
    2. Rename to testFieldName
    • EXPECTED RESULT: 5/5 occurrences were updated
  8. Refactoring 1.5 - Rename Annotation Type
    1. Open abc.def.DAnnotType and select DAnnotType
    2. Rename to AnnotType
    • EXPECTED RESULT: 13/17 occurrences
  9. Refactoring 1.5 - Rename Annotation Type Member
    1. Select coord in abc.def.DAnnotType
    2. Rename to dcoord
    • EXPECTED RESULT: 2/2 occurrences
  10. Refactoring 1.5 - Move Class I
    1. Open abc.A
    2. Move Class to abc.def
    • EXPECTED RESULT: 14 occurrences, project should be compilable
  11. Refactoring 1.5 - Move Class II
    1. Open abc.En
    2. Move Class to abc.def
    • EXPECTED RESULT: 8 occurrences, project should be compilable
  12. Refactoring 1.5 - Encapsulate Fields
    1. Select field list in abc.A
    2. Encapsulate Fields - default (encapsulate only list, field visibility private, accessor visibility public, use accesors even if field is visible true)
    • EXPECTED RESULT: All occurrences of list in abc.A and abc.B should be replaced, the generated methods should have generics types
  13. Refactoring 1.5 - Change Signature
    1. Select methodA(T, String, boolean, String...) in abc.A
    2. Change Method Parameters - make some changes
    • EXPECTED RESULT: Verify that the result is correct


TS 60 Refactoring2

Introduce Method

Original Test Specification: TS_60_Refactoring2
Project: Refactoring

  1. New method without return statement
    1. In packageA.ClassA select text between marks //1 and //2
    2. Introduce Method - any name + access private + uncheck "Replace Also Other Occurrences(1)"
    • EXPECTED RESULT: The new method is created containing the selected code
  2. New method - cancel
    1. In packageA.ClassA select text between marks //1 and //2
    2. Introduce Method - any name + Cancel button
    • EXPECTED RESULT: No changes are performed
  3. Method with return statement
    1. In packageA.ClassA select the code form mark //3 to //4
    2. Introduce Method (by quick fix menu - alt-enter) - any name + access private + uncheck "Replace Also Other Occurrences(4)"
    • EXPECTED RESULT: New method without any parameters is created. The original place is modified that the variable c is initialised by method's call
  4. Method with return statement 2
    1. In packageA.ClassA select the code form mark //4 to //5
    2. Introduce Method - any name + access private
    • EXPECTED RESULT: Checkbox "Replace Also Other Occurrences" is disabled. The new method with two parameters is created. The method contains return statement. At the original place there is assignment of method's result to a single variable
  5. Ending with return/break/continue
    1. In packageA.ClassA mark code between //7 and //8
    2. Introduce Method - perform refactoring + undo
    3. Change gradually the continue command to break and than to return
    • EXPECTED RESULT: After performing refactoring with last statement continue; or break; a new method with return statement is created. With return; as a last statement is type of new method void. The original selection is replaced with method call
  6. Illegal refactoring - wrong selection
    1. Open some file (e.g. packageA.ClassA)
    2. Select part of the command, expression or line and call Introduce Method
    3. Selecting whole class and call Introduce Method
    4. Call Introduce Method on items from Navigator (by selecting them and using main menu Refactor)
    • EXPECTED RESULT: In all these cases the Introduce Method should be disabled or the error message "Invalid Selection." should be popped up
  7. Illegal refactoring - too many outputs
    1. In packageA.ClassA select code between //0 and //1
    2. Introduce Method
    • EXPECTED RESULT: Error message announcing "Too many return values." is popped up
  8. Illegal refactoring - selection contains return/break/continue
    1. In packageA.ClassA mark code between //6 and //7
    2. Introduce Method - perform refactoring + undo
    3. Change gradually the continue command to break and then to return and repeat steps 2) and 3)
    4. Comment out the line 57 ("s = s+"--, ";") and try again
    • EXPECTED RESULT: The error message "Too many return values" is displayed at first. After commenting out the specified line, the refactoring can be performed and semantic of the code is not changed TO DO
  9. Illegal refactoring - method already defined
    1. Open file packageA.ClassA
    2. Select the code form mark //4 to //5
    3. Call Refactor -> Introduce Method
    4. Change method name to existing
    5. Confirm dialog
    6. Repeat whole testcase, but change name to existing2 and existing3
    • EXPECTED RESULT: For existing and existing2 an error dialog is shown, announcing that the method with the same signature already exists. Method's name existing3 is OK
  10. Global variables
    1. Open file packageA.ClassA
    2. Select the code form mark //9 to //10
    3. Call Refactor -> Introduce Method
    • EXPECTED RESULT: The new method without any parameter and without return is created.
  11. Modifiers manipulation
    1. Go back to some previous test case
    2. Try changing access modifier
    • EXPECTED RESULT: Method is created with correct modifier
  12. 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
  4. Negative case - wrong selection
    1. Select part of code which in not an expression (part of identifier, line with ending ';', etc...)
    2. Open hint menu (Alt-Enter)
    3. Call Refactor -> Introduce Field
    • EXPECTED RESULT: The list of available hints (if there are any) does not contain Introduce Field. When invoking action from menu the error "Wrong selection" is shown.
  5. Negative case - existing identifier
    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. Fill name of existing field as field name
    5. Press OK
    • EXPECTED RESULT: The warning that field already exist should be shown
  6. Negative case - wrong location
    1. Open file packageE.ClassA
    2. Select text "a" on the line where field "konst" is declared
    3. Use Alt-Enter to show list of possible hints and select
    • EXPECTED RESULT: Introduce field hint should not be provided


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 - change access modifier
    1. Repeat previous test case, but change access modifier
    2. Use list of hints to call Introduce constant
    • EXPECTED RESULT: Introduced constant has desired modifiers
  3. Introduce constant - negative case
    1. Open file packageE.ClassB
    2. Select part of code which cannot be turned into the new constant (whole line, part of identifier, etc...)
    3. Try fill in existing or invalid identifier
    • EXPECTED RESULT: If wrong part of code is selected the Introduce constant hint is not provided, invoking this action from menu open error dialog. Used or invalid identifier is detected and transformation is not performed in such situation
  4. 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
  3. Introduce variable - negative testcase
    1. Open file packageE.ClassC
    2. Select invalid part of code
    3. Try Introduce variable
    • EXPECTED RESULT: Hint Introduce variable is not provided. Error message is shown when calling action from Refactor menu


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. Refresh button
    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. Press Cancel
    • EXPECTED RESULT: After clicking on Refresh the refactoring dialog is reopened in the state as it was left. Cancel button cancels refactoring w/o preforming any changes
  3. 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.
  1. 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.
  2. Extract from class implementing interface
    1. Open file packageB.ClassC
    2. Call Extract Interface on it
    3. Enter new interface name, select "implements Runnable" and at least one more member
    4. Press Preview
    5. Perform refactoring
    • EXPECTED RESULT: In the preview there are correctly listed all changes. After finishing refactoring the new interface implementing runnable and containing selected methods is created. The original class now implements new interface.
  3. Extract from file with more toplevel elements
    1. Open file packageB.ClassD
    2. Put cursor in editor to class ClassD
    3. Perform Extract Interface
    4. Repeat steps 2 and 3 for each toplevel element and for the inner class
    5. Try refactoring when caret is in the space between elements (lines: 10, 12, 33, 39, 43)
    • EXPECTED RESULT: Every refactoring is performed with the proper element. When invoked from space between elements the refactoring is performed with ClassD class.
  4. Invalid refactorig
    1. Go back to any previous case and invoke Extract Interface dialog
    2. Try fill in invalid or already existing name
    3. Try also fill in the name of the original class
    • EXPECTED RESULT: In all case the error messages with clear and correct meaning should by shown.


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. Extracting from file with more top level elements
    1. Open packageC.ClassC
    2. Try to invoke refactoring from different places of the source code
    3. Try to call refactoring from different positions from the project view .
    4. Perform Extract Super Class for class TopLevelElement
    • EXPECTED RESULT: Every time the dialog is opened it has right context. If it is called from the editor when cursor is outside of any element (e.g. lines 10. 30, 35) or from the node corresponding to java file the context is set to ClassC.
  4. Extracting from interface, enum and annotation
    1. Open class packageC.classD
    2. Try to call Extract super class for Interface, Annotation and Enum element.
    • EXPECTED RESULT: In all 3 cases a message saying the refactoring can not be performed is popped up.
  5. 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.
  6. Refactorning class with import
    1. Open packageC.ClassF
    2. Call Refactor -> Extract Super Class
    3. Select method method() to be extracted
    4. Confirm refactoring
    • EXPECTED RESULT: New super class is created and it is containing method method(). All imports statements are updated correctly in both files.
  7. Invalid refactoring
    1. Call Extract Super Class on some class as in previous test cases.
    2. Try to fill in invalid class name (e.g. '1NewClass' or some keyword)
    3. Try to fill in existing class name
    • EXPECTED RESULT: In all cases the user should be informed that the refactoring is impossible. The error message should clearly described why the refactoring is unsuitable.


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. Basic Safe Delete
    1. Open packageD.ClassA
    2. Select variable i at the line 19
    3. Call Refactor -> Safely Delete
    4. In the Safe Delete dialog press Preview
    5. Click on Show Usages
    6. In Find Usages result window press Refresh button
    • EXPECTED RESULT: The 'Safe delete' dialog is opened. It is clear, which element is going to be deleted. After confirming a new dialog is opened informing that usages had been found. In the 'Show usages' window, there are listed both usages. Refresh button will bring back original Safe delete dialog
  2. Basic Safe Delete II
    1. In opened file ClassA remove line 22 ( i = 1)
    2. Call Refactor -> Safely Delete on element i
    3. Check Search in Comments and confirm dialog
    4. Click on Show Usages
    5. Click on Return Safe Delete
    6. Uncheck Search in Comments and press Preview
    7. Confirm action
    • EXPECTED RESULT: At a first try a dialog informing about found usages is opened. After clicking on Show usages, one usage (in comment) is shown. The second try of safe delete is OK, in the preview there are listed all changes to be done. After refactoring the declaration of i is deleted.
  3. 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.
  4. 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.
  5. Deleting locally referenced items
    1. Open packageD.ClassC
    2. Try to safely delete field field, method method() and inner class Inner
    3. Delete method user()
    4. Repeat step 2.
    • EXPECTED RESULT: In step 2 any of the elements cannot be deleted, because they are used in method user(). When this method is deleted these elements can be safely deleted.
  6. Deleting from project view
    1. Select packageD.User in the project
    2. Press delete
    3. Check safe delete checkbox
    4. Confirm
    • EXPECTED RESULT: The safe delete action is performed


Refactoring Test Specification for

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 Availability
    1. Check presence of Pull Up item in menu Refactor
    2. Select package pull in the project windows and check in Pull Up is disabled both in Refactor | Pull Up and context menu.
    3. Select node corresponding to VIPCustomer.java in project view and call Pull Up
    4. Open VIPCustomer class in editor and call Pull Up .
    • EXPECTED RESULT: Pull Up is present in the menu and is disabled for package scope. When called in the class scope and in editor the dialog is opened. It has correct title and provides all inner elements which can be pulled up.
  2. 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)
  3. Pull Up two and more levels
    1. Invoke Refactor | Pull Up for RegularCustomer class in Editor
    2. Check some fields and methods from the list, select BaseCustomer class as Destination Supertype.
    3. Click Preview, review all changes and click Do Refactoring
    • EXPECTED RESULT: Selected elements should be propagated to desired class. Repeat the testcase once more and select class BaseCustomer as Destination Supertype.
  4. 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)
  5. Pull up private elements
    1. Invoke Refactor | Pull Up for BaseCustomer class
    2. Check all private elements
    3. Click Preview, review all changes and click Do Refactoring
    • EXPECTED RESULT: All selected elements are moved to superclass and their modificator is changed to protected
  6. Pull Up selected elements
    1. Open VIPCustomer in editor
    2. Put caret on element which can be pulled up (note: this doesn't work for elements with further inner elements such as classes, inner ifaces etc..)
    3. Call Refactor | Pull Up
    • EXPECTED RESULT: The element under caret is checked in the refactoring dialog
  7. Pull Up implemented interfaces
    1. Invoke Refactor | Pull Up for Implementor class
    2. Select all interfaces to be pulled up
    3. Click Preview, review all changes and click Do Refactoring
    • EXPECTED RESULT: The implementation statement is pulled up to superclass
  8. Pull Up w/o preview
    1. Invoke Refactor | Pull Up for BaseCustomer class
    2. Select some elements, Refactor
    • EXPECTED RESULT: Refactoring is performed w/o any further questions
  9. Pull Up refresh
    1. Invoke Refactor | Pull Up for VIPCustomer class
    2. Select some methods, change Destination Supertype and confirm by pressing Preview
    3. In the preview window press refresh button (that one with green arrow)
    • EXPECTED RESULT: Dialog is reopened, selection of elements is restored as it was before confirming dialog, destination supertype has desired value.
  10. Pull Up cancel
    1. Invoke Refactor | Pull Up for VIPCustomer class
    2. Select some elements and press Preview
    3. In preview press Cancel
    • EXPECTED RESULT: Action is canceled, no changes were done in the code
  11. 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.
  12. Pull Up - no elements
    1. Invoke Refactor | Pull Up for ClassWithNoMembers class
    • EXPECTED RESULT: Error messages "The selected type and its supertypes have no members that could be pulled up." is shown. Action cannot continue.
  13. Pull Up - no elements selected
    1. Invoke Refactor | Pull Up for VIPCustomer class
    2. Keep all checkboxes unchecked
    3. Press Preview
    • EXPECTED RESULT: In step 2 error "No members are selected to be pulled up." is shown in the lower part of the dialog. In step 3 dialog contains only error message and action cannot continue.
  14. Pull Up undo
    1. Repeat some of the testcase
    2. Use Undo
    • EXPECTED RESULT: All changes are reverted.
  15. Pull up from interface
    1. Invoke Refactor | Pull Up for SubInterface class
    2. Select some elements
    3. Click Preview, review all changes and click Do Refactoring
    • EXPECTED RESULT: Selected elements are moved to super interface. In the 'Destination Supertype' there are listed all interface convenient as target classes.
  16. 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 selected element
    1. Open SuperBaseClass in editor
    2. Put caret on element which can be pushed down (note: this doesn't work for elements with further inner elements such as classes, inner ifaces etc..)
    3. Call Refactor | Push Down
    • EXPECTED RESULT: When caret is located in pushable element the relevant checkbox is checked in the refactoring dialog.
  3. Push Down implemented interface
    1. Invoke Refactor | Push Down for MySuperClass class
    2. Select implementing Serializable in the dialog
    3. Click Preview and click Do Refactoring
    • EXPECTED RESULT: The class MySubClass will now implement Serializable instead of MySuperClass
  4. 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.
  5. Push Down w/o preview
    1. Invoke Refactor | Push Down for SuperBaseClass class
    2. Select some elements and press Refactor
    • EXPECTED RESULT: Refactoring is performed w/o any further questions.
  6. Push Down refresh
    1. Invoke Refactor | Push Down for SuperBaseClass class
    2. Select some elements and confirm by pressing Preview
    3. In the preview window press refresh button (that one with green arrow)
    • EXPECTED RESULT: Dialog is reopened, selection of elements is restored as it was before confirming dialog.
  7. Push Down cancel
    1. Invoke Refactor | Push Down for SuperBaseClass class
    2. Select some elements and press Preview
    3. In preview press Cancel
    • EXPECTED RESULT: Action is canceled, no changes were done in the code.
  8. Push Down - no subtype
    1. Invoke Refactor | Push Down for EmptyClass2 class
    • EXPECTED RESULT: Error "Cannot push down any members. The selected type has no subtypes in the currently opened projects." is displayed. Action cannot continue.
  9. Push Down - no elements
    1. Invoke Refactor | Push Down for SuperSuper class
    • EXPECTED RESULT: Error "The selected type has no members that could be pushed down." is displayed. Action cannot continue.
  10. Push Down - no elements selected
    1. Invoke Refactor | Push Down for SuperBaseClass class
    2. Keep all checkboxes unchecked
    3. Press Preview
    • EXPECTED RESULT: Dialog with message "No members are selected to be pushed down." is displayed. Action cannot continue.
  11. Push Down undo
    1. Repeat some of the testcase
    2. Use Undo
    • EXPECTED RESULT: All changes are reverted.
  12. 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 - interfaces
    1. Call Move Inner to Outer Level for class InnerIface located in OuterClass
    2. In the dialog change Class Name
    3. Click Preview, review all changes and confirm by Do Refactoring
    • EXPECTED RESULT: Interface is moved to separate file. Reference in class User is updated
  4. Inner to Outer - enum
    1. Call Move Inner to Outer Level for enum InnerEnum located in OuterClass
    2. In the dialog change Class Name
    3. Click Preview, review all changes and confirm by Do Refactoring
    • EXPECTED RESULT: Enum is moved to separate file. Reference in class User is updated
  5. Inner to Outer - annotations
    1. Call Move Inner to Outer Level for class InnerAnot located in OuterClass
    2. In the dialog change Class Name
    3. Click Preview, review all changes and confirm by Do Refactoring
    • EXPECTED RESULT: Annotation is moved to separate file. Reference in class User is updated.
  6. Inner to Outer - fix imports
    1. Call Move Inner to Outer Level for class FileHandler located in Wrapper class
    2. Keep all defaults and perform refactoring
    • EXPECTED RESULT: Class is moved to a separate file with all necessary imports.
  7. 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.
  8. Inner to Outer - two levels
    1. Call Move Inner to Outer Level for class InnerInnerClass located in Wrapper class
    2. Keep all as default, perform refactoring
    3. Call Move Inner to Outer Level for class InnerInnerClass again
    4. Keep all as default, perform refactoring
    • EXPECTED RESULT: The InnerInnerClass class is step by step propagated to outer level. The reference to previous outer classes are added to constructor.
  9. Inner to Outer - w/o preview
    1. Call Move Inner to Outer Level for class Inner1 located in OuterClass
    2. In the dialog uncheck Preview All Changes
    3. Click Refactor
    • EXPECTED RESULT: Action is performed w/o preview.
  10. Inner to Outer - cancel
    1. Call Move Inner to Outer Level for class Inner1 located in OuterClass
    2. Click Preview
    3. In preview click Cancel
    • EXPECTED RESULT: There are no changes in the code.
  11. Inner to Outer - refresh
    1. Call Move Inner to Outer Level for class Inner1 located in OuterClass
    2. In the dialog change Class Name and Field Name
    3. Click Preview
    4. In preview click Refresh (button with the green arrow)
    • EXPECTED RESULT: The refactoring dialog is reopened, all values are restored.


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 [[../data/ConvertClasses_TS_60_Refactoring3.zip| ConvertClasses]]

  1. Anon to Inner availability
    1. Check presence of Convert Anonymous Class to Inner item in menu Refactor
    2. Select package node and class node and check that menu item is disabled
    3. Open some java file and put carent into it -> the menu item is enabled
    4. Place cursor over identifier of supertype in anonymous class declaration (e.g. over second word Runnable in "Runnable r = new Runnable() { ... }") -> hint Convert anonymous ... is provided
    • EXPECTED RESULT: The menu item is avaiable and it's enable/disable status follow previous description.
  2. 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.
  3. Anon to Inner - constructor
    1. Open ClassB in editor and call refactoring for its anonymous class.
    • EXPECTED RESULT: The new inner class is created. It's constructor accepts one parameter and delegates is to super class.
  4. Anon to Inner - static
    1. Open ClassD in editor and call refactoring for its anonymous class.
    • EXPECTED RESULT: The new class is declared as static, since it used in static context.


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 [[../data/ConvertClasses_TS_60_Refactoring3.zip| ConvertClasses]]

  1. Use Supertype - availability
    1. Check presence of Use Supertype Where Possible item in menu Refactor
    2. Browse through the structure of class usesupertype.Sub in projects window, call Use Supertype Where Possible for each type of element.
    3. Open Sub in editor and call refactoring from various position in the class
    • EXPECTED RESULT: Use Supertype Where Possible is enabled available for classes, e.g form node corresponding to java file and form node corresponding directly to the class.
  2. 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 retyped to Object.
  3. Use Supertype - select type
    1. Call Use Supertype Where Possible for class Sub
    2. Select one item form the list
    3. Click Preview, review all changes and confirm by Do Refactoring
    • EXPECTED RESULT: The identifiers s? should be typed according to the selected type.
  4. Use Supertype - w/o preview
    1. Call Use Supertype Where Possible for class Sub
    2. Select one item from the list, uncheck Preview All Changes
    3. Click Refactor
    • EXPECTED RESULT: The action is performed w/o preview
  5. Use Supertype - cancel
    1. Call Use Supertype Where Possible for class Sub
    2. Select one item from the list,
    3. Click Preview.
    4. In the preview click Cancel
    • EXPECTED RESULT: Refactoring is canceled, no changes are made to the code.
  6. Use Supertype - refresh
    1. Call Use Supertype Where Possible for class Sub
    2. Select one item from the list
    3. Click Preview
    4. In preview click Refresh (button with the green arrow)
    • EXPECTED RESULT: Dialog is reopened, previous selection is restored.


Call Hierarchy

Test suite: Call Hierarchy

Setup:
- Start IDE with a fresh userdir. Download and unzip projects File:SampleProjects TS 65 CallHierarchy.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 - Scope for invoking
    1. Right-click the comment on line 28 in main.java and invoke Call Hierarchy
    • EXPECTED RESULT:
      - Call Hierarchy for the right-clicked method (which is a "main" method in this case) is displayed in "Java Call Hierarchy" view.
      - Switching from Callers to Callees using toggle buttons works as expected (no methods calling "main" are displayed when exploring callers, methods called from "main" are displayed in the tree when exploring callees).
  5. Call Hierarchy - Refresh
    1. Right-click the comment on line 28 in main.java and invoke Call Hierarchy
    2. Click "Show Hierarchy of Callees" toggle button to show methods called from the "main" method
    3. Delete the first '/' character from the comment on the line 28 to comment-out a portion of code
    4. Click the Refresh button in "Java Call Hierarchy" view
    5. Add the '/' character back to uncomment a portion of code
    6. Click the Refresh button in "Java Call Hierarchy" view again
    • EXPECTED RESULT: Method "CapFirstLetter" is present in the call hierarchy tree (as a callee) if it is called in the main method (in other words, if it is not commented-out in the code).
  6. Call Hierarchy - Invoking outside method
    1. Right-click anywhere on line 1 and invoke Call Hierarchy
  7. 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
  8. 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.
  9. Call Hierarchy - Go to source (Particular occurrence)
    1. Open NewClassRecursive.java in the editor
    2. Invoke Call Hierarchy from the popup menu above the "fib" method on line 14
    3. Click the only sub-node in the tree (the one with a badge indicating recursive call) in order to display lines with method call in the bottom of "Java Call Hierarchy" view
    4. Double-click some of the lines with a method call or invoke Go to source from the popup menu
    • EXPECTED RESULT: You are navigated to the particular call you selected.
  10. 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
  11. Call Hierarchy - Scope to Search
    1. Open main.java in the editor, if it is not already opened
    2. Invoke Call Hierarchy from the popup menu above the "CapFirstLetterOfEachWord" method on line 45
    3. Click Show Hierarchy of Callers (again, just to ensure you are viewing callers of "CapFirstLetterOfEachWord" method)
    4. Click Scope to Search button in the "Java Call Hierarchy" and choose Current Project from the popup menu
    5. Click Refresh button in the "Java Call Hierarchy" view
    6. Click Scope to Search button again and choose Open Projects
    7. Click Refresh button again
    • EXPECTED RESULT:
      - Call made from callhierarchydep.Main is not present in the results when you press the Refresh button for the first time, as it is not in the current project.
      - Call made from callhierarchydep.Main is again present in the results after you press the Refresh button for the second time.
  12. Call Hierarchy - Invoking in Java file
    1. Open file MyClass.java from project CallHierarchyDep (only the file, not the project)
    2. Right-click in the editor and see the popup menu ("Call Hierarchy" is disabled now)
    3. Double-click main(String[[ | ]] args)::callhierarchydep sub-node in the call hierarchy tree (should be still there from the previous case)
    4. When "callhierarchydep.Main" is opened, invoke popup menu above "CapFirstLetterOfEachWord" method on line 19 ("Call Hierarchy" is disabled now)
    5. Open project "CallHierarchyDep"
    6. Invoke popup menu above "CapFirstLetterOfEachWord" method on line 19 in callhierarchydep.Main class again
    • EXPECTED RESULT:
      - Popup menu item "Call Hierarchy" is enabled only in case that project is opened - it is not enabled in case that only a file is opened.
      - Popup menu is enabled in a file after a project containing that file is opened in IDE.
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