Skip to main content

Reviewing step implementations

A Gherkin step is a sentence; the step method is the code that sentence runs. Checking that a scenario tests what the spec file claims means reading each step method beside the step, and the method may sit in the concrete test class, in a base class or in an interface of shared steps. With Follow caret in spec file switched on, the Test Code pane finds the method for each step, so reading the spec file from top to bottom brings up each step's code on the way.

Reading each step's method​

Follow caret in spec file Follow caret in spec file toggle is the toggle at the right end of the Test Code pane's toolbar, next to Highlight Matching Lines.

Switch the toggle on, then put the caret on a step in the spec file pane, on the left. The Test Code pane, on the right, opens the class that implements the step — the concrete test class, a base class or an interface — scrolled to the step method, and the tab of that class becomes the selected tab. Move the caret down the spec file to the next step and the Test Code pane follows, changing files whenever the next step method lives in a different class.

With Highlight Matching Lines on, the step and the step method's declaration are highlighted together, joined by the band across the divider. A step used several times pairs with the same method from every use.

Lines that are not steps open the generated class instead: a Scenario: title lands on the test method, the Feature: title on the class declaration, a description line on the matching line of Javadoc.

Watch the tabs: the selected tab changes whenever the next step method lives in another class.

Steps grouped in interfaces​

Step methods do not have to sit in one class. A project can group them by domain into interfaces — cart steps in one, checkout steps in another — written as default methods, with the marker class implementing every interface the spec file needs. The concrete test class is then left with nothing but the state those methods share.

Following treats an interface like any other class. The Test Code pane adds a tab for each interface, and moving the caret down the spec file switches to that tab whenever the next step method is declared there.

Two interfaces of steps, one tab each: the pane changes tab where the scenario moves from cart steps to checkout steps.

Other cases​

A step with no implementation yet​

A step that no class implements yet has no method body to show. Following then opens the generated class at the call generated for that step — the line to start from when writing the missing step method.

Looking at another class while following​

With Follow caret in spec file switched on, the tabs can still be clicked to read another class. That class stays on screen only until the caret is moved to a different step in the spec file. The Test Code pane then switches back to the class that implements the new step. To keep one class on screen, switch Follow caret in spec file off.

Steps from a library​

A step method inherited from a compiled dependency — a shared library of steps, say — still gets a tab, marked on the tab's icon as library code. Choosing that tab shows decompiled code, not the library's source: the tab is there to say where the step comes from when the project has no source for the step method.