Refactoring steps

A step method's name is derived from the step's text, so the same wording appears both in the spec files and in the Java code. A change to one has to be matched in the other, and the IDE's refactoring commands make both changes at once: change a step method in the Java code, and the plugin writes the new wording into each related step, in every spec file that uses the step. To see those places before changing anything, use Find Usages — covered on Finding step usages.

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.

Rename (Shift+F6) on the step method

The new name, typed into the Rename dialog

Preview, to see every file the rename touches

Expand All, to list each usage

Both spec step lines the rename will change

Refactor applies it

One rename of the step method

and the step lines in the spec files follow

Checkout.specb changed too, unopened

One rename, two spec files. The step becomes I put "Wireless Headphones" in cart with quantity "2" at price "59.99" — same three values, new words around them — and Checkout.specb, never shown during the refactoring, changed with it.

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.

Change Signature (Cmd+F6) on the step method

In$p2 added to the name

Add a currency parameter

The step gains "EUR" where the name has $p2

Change Signature adds a parameter, and the step gains its default value at the position of the new placeholder in the name.

Change Signature (Cmd+F6) again

Remove the parameter

and In$p2 from the name

The step loses that value

Remove a parameter, and the step drops the value that belonged to it.

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, in one step.

You can start the rename at each occurrence: at a step, at a subsequent step, or at the header cell.

Rename (Shift+F6) on the placeholder

The Rename Outline Parameter dialog asks only for the new name

One rename: step, doc string, table cell, Examples header

One rename, four places — the step, the JSON doc string, the data-table cell and the Examples header, as the gutter's change bars show. The outline further down the file keeps its own <product>: same word, different parameter, left alone.