How to write declarative Cucumber features for describing CRUD operations?

Question

I understand the difference between imperative and declarative cucumber steps, but I have not seen any real world examples of this. I always feel like my feature files are becoming too verbose.

It seems like there would need to be a cucumber feature for each step in the life cycle:

• foobars/list_foobars.feature
• foobars/create_foobar.feature
• foobars/view_foobar.feature
• foobars/edit_foobar.feature
• foobars/delete_foobar.feature

In the create feature alone, it seems like you would want to list out the fields that can be entered, which ones are required, what happens when you enter invalid data, etc. I don't know of a declarative way to do this. Of course in subsequent features, you would just say Given a foobar exists rather than going through all the steps to create one.

How detailed do you go when describing your application's behavior? Can you provide some examples of feature files that you feel are acceptably complete?

Answer 1

I like to keep cucumber tests human readable, so assuming we have a story for editing a foobar with invalid data, I'd want a scenario like:

# foobars/edit_foobar.feature
Feature: As a user, I want to edit a Foobar, so I can Baz

Scenario: Validation Errors
  Given I am logged in as a user
  And a foobar exists
  And I edit the foobar with invalid data
  Then I should see validation errors

I think that captures what we want out of the story, without having to deal with all the details of which fields to edit, what buttons to submit, etc. It doesn't test all the possible cases, but those should really be tested via unit tests (model tests that the validations are set, and controller tests that the flash messages are set or request tests that the errors are being served).

The other scenarios are similar:

Scenario: Successful Edit
  Given I am logged in as a user
  And a foobar exists
  And I edit the foobar with valid data
  Then I should see the valid data

Some people will want to specify the valid data as part of the test itself, but I personally prefer to delegate these to the step definitions in order to keep the scenarios clean. You just need one example to make sure the golden case works, because again this isn't the appropriate place to test that all the form fields work (and it will become a maintenance headache if you do specify every single field).