Refactoring
A spec file and its step methods hold the same wording in two places. If you change one of them, the other must change also. The refactoring commands of the IDE do this for you. You change a step method in the Java code. The plugin writes the new wording in each related step, in all spec files where that step is used.
Rename of a step method
Invoke Rename on a step method and give it a new name. The plugin writes the new wording in each related step. Thus one operation changes the code and the spec files together.
A step can contain parameter values in quotation marks. The plugin keeps these values, and changes only the words around them:
- if the new name has an additional value, the step gets an empty position for it
- if the new name has one value less, the plugin deletes that value from the step
- if the new name has the values in a different sequence, the plugin moves them
A doc string or a data table below the step stays unchanged.
<The Rename dialog on a step method, and the same step in the spec file after the rename, with its quoted value still in position.>
Change of a step method signature
Add, remove or move the parameters of a step method. The plugin changes the values in each related step. Thus the steps agree with the new signature.
The plugin puts the default value of a new parameter in the correct position. This is possible at the end of the step, in the middle of the step, and in a step that has no values. If you remove a parameter, the plugin deletes its value. You can also change the name and the parameters in one operation.
Find Usages
Invoke Find Usages on a step method. The IDE lists the step lines in the spec files that use that method, and not only the calls in the Java code. Thus you can see where a step is used before you change it.
The list contains all the occurrences. A step that occurs two times in the same scenario occurs
two times in the list. The list also contains the background steps, and the steps that start with
And, But or *.
<The Find Usages tool window with step lines from two spec files as the results, and the spec file open behind it at one of them.>
Rename of a placeholder in a scenario outline
A scenario outline gets its values from the Examples table below it. Each column of that table
has a name, and the steps refer to the name in angle brackets, for example <username>. The name
must be the same in the table and in each step that uses it.
This refactoring starts in the spec file. Invoke Rename on a placeholder and give it a new
name. The plugin changes each occurrence: each step that uses the placeholder, a doc string that
contains it, and the header cell of the Examples table. Thus the scenario outline stays correct
after the change.
You can start the rename at each occurrence: at a step, at a subsequent step, or at the header cell.
<A Scenario Outline with a placeholder highlighted in a step, in a doc string and in the Examples header, to show the three places that the rename changes.>