Error-testing be with cucumber/capybaraweb

Question

I'm working on writing tests for a rails application using cucumber and capybara. I have a scenario for a user editing a post, and making it invalid.

The scenario looks like this:

Scenario: I edit a post and make the data invalid.
  Given I have 1 post
  And I view my 1st post
  Then I click "Edit"
  And I fill in the edit post form with bad data
  When I click the "Update post" button
  Then I should see "Title is too short (minimum is 3 characters)"
  And I should see "Body is too short (minimum is 30 characters)"

Should I leave the scenario as-is, or create a scenario for entering the title incorrectly, and another scenario for entering the body incorrectly, like this:

Scenario: I edit a post and make the title too short.
  Given I have 1 post
  And I view my 1st post
  Then I click "Edit"
  And I fill in the edit post form with a title that is too short
  When I click the "Update post" button
  Then I should see "Title is too short (minimum is 3 characters)"

Scenario: I edit a post and make the body too short.
  Given I have 1 post
  And I view my 1st post
  Then I click "Edit"
  And I fill in the edit post form with a body that is too short
  When I click the "Update post" button
  Then I should see "Body is too short (minimum is 30 characters)"

If the post has several more fields, should I still create a scenario for each one, or would it be more DRY to use one scenario?

Answer 1

Personally, I only write feature tests for critical and very common cases, and outsource more specific tests (i.e is a certain field on a model validated) to model specs.

I wouldn't consider it a feature that a certain validation error is shown to the user, but I consider it a feature that the user gets informed that something went wrong and his post couldn't be created.

TL;DR Test the user experience in a feature spec and data integrity in model / controller specs.

Use different thinking hats for different tests:

• Feature tests: Think in the user's perspective, how does the user interact with your app? what is the user expecting from your app?
• Model tests: Think compulsive orderliness, how can you ensure data integrity?
• Controller tests: Think paranoid, who can access what? does your controller comply with your API specs?

I would test in a feature spec for a "post":

• That the user is able to create a post with an expected set of information (i.e the minimum that is required to create a post) and is redirected to the new post which shows the entered information.

• That the user is unable to create a post by just hitting the "Submit" button without filling anything in and is shown a validation error. After correcting the user's mistake he should be able to create the post and be redirecred to the new post which shows the entered information.

This ensures the following "features":

• Posts can be created
• The user is informed about mistakes
• Mistakes can be fixed
• The user is assured that his post has been created.

I would test in a model spec:

Spec.describe Post, type: :model do
  subject { create(:post) }

  context 'validations' do
    it { should validate_presence_of(:title) }
    # for my taste, it's good enough to test that we validate the length
    it { should validate_length_of(:title) }

    it { should validate_presence_of(:body) }
    # if you want to be super-strict, you can check the length
    it { should validate_length_of(:body).is_at_least(100) }
  end
end

Answer 2

I personally would use a Scenario Outline in this situation.

Feature: Shortest Length Validation

Rules
 - Title must be more than 3 characters long
 - Body must be more than 30 characters long

Scenario Outline: I edit posts making various lengths too short.
  Given I have 1 post
  And I view my 1st post
  Then I click "Edit"
  And I fill in the edit post form with a <type> that is too short
  When I click the "Update post" button
  Then I should see "<capType> is too short (minimum is <minLength> characters)"

Examples:
| type  | minLength | capType | 
| title | 3         | Title   |
| body  | 30        | Body    |

If you want to add more to it, you can add more to the table, and replace the values to change with the heading of the column that you would like to replace it with, in between these brackets: <>.

If you wish to make lots of Scenarios that fundamentally do the same thing but in different ways, this is almost definitely the best way of doing it.