debugrubyrailsMinor
Error-testing be with cucumber/capybaraweb
Viewed 0 times
cucumbererrorwithtestingcapybaraweb
Problem
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:
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:
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?
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?
Solution
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:
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":
I would test in a model spec:
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
endCode Snippets
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
endContext
StackExchange Code Review Q#124592, answer score: 7
Revisions (0)
No revisions yet.