[jedifans]

Try not to see a feature file as a way to automate tests but to capture the requirements in a language that isn't technical.

Business rules change far less often than implementations, so the feature files shouldn't be tied to the implementation - that tying together can happen in the ruby code that implement the steps. You can refactor that code easily but the feature is denoting the business rule.

[yebyen]

It is both, though!

If you're using Cucumber (and not Spinach or Turnip) you need every (mechanically) different step to be (verbally) unique.

So they need to be descriptive enough to distinguish them from something not quite the same. They don't necessarily need to be descriptive enough to mechanically identify every button and selector used in English language, but they should not be so ambiguous that you could choose a different way and reach a different result.

The coolest thing I found is the ability to compose step definitions. So in my customer-level Gherkin, let's say I have some two-man workflow built around activities managing employee users, I can ultimately say:

"When I disable a user"

and I can implement this as

  When(/^I disable a user$/) do
    step "I select the user \"example user\""
    step "I enter a termination date of today"
    step "I select a termination reason of \"fired\""
    step "Review Form is clicked"
    step "Submit is clicked"
    step "I log in as HR"
    step "I pull up the submitted activity"
    step "Complete is clicked"
    step "I log in as Payroll"
    step "I pull up the submitted activity"
    step "Complete is clicked"
  end

and I still haven't written a touch of Capybara or Ruby, but I've decoupled the business rule from the mechanical process.

This is the greatest power feature of Cucumber, in my opinion.