Why not to use Strings in Cucumber

Cucumber allows you to define step definitions using strings instead of regular expressions.

This might seem simpler at first, but it has other problems, which I’ll illustrate with an example.

Here is a step definition that uses a plain string.

Given “I have 100 in my Account” do

end

We couldn’t write $100 here, because the $ has a special meaning when you define step definitions with strings.

Any $ signs—including any letter or number following it—will be interpreted as an argument, .

This step definition uses an argument:

Given “I have $amount in my Account” do |amount|

 

end

This step definition would match both of the following Gherkin steps:

Given I have 100 in my Account

Given I have $100 in my Account

 

In the first case, the Step Definition’s amount argument would have the value “100”. In the second case it would have the value “$100”. If our Step Definition expects a string with only digits, this can be problematic. We have no way to enforce a consistent way to write Gherkin steps, and the step definitions have to anticipate many kinds of input.

 

This is why using strings instead of regular expressions is not as advantageous as you might think. They give far less control over what gets matched and what arguments a step definition can receive.