From what I understood this morning, the concern Steve had was to be able to use the acceptance specs as a communication tool with the clients, whether directly (the clients read it) or indirectly (the clients do not read it).
The concern from me (at least) is the maintainability of the Cucumber steps. Here are some example:
- Projects where there were so many cucumber steps that it became hard to figure out what each step did
- Projects that tried to be too DRY with the steps the regexps became difficult to handle
- Projects where a lot of set up was required, and the steps to create the users like became long and too descriptive (
Given an active user exists that last logged in 2 years ago) - Projects whose Cuke steps shared World-wide variables (
@project) that were used across steps
For me, using Capybara directly solves this. But, I must agree that only developers can read them. Why not have the best of both worlds?
Given this rspec file:
feature 'User can disable their own account' do
background do
given 'a user Bob exists' do
@user = FactoryGirl.build_stubbed(:activated_user,
username: 'Bob')
end
end
scenario 'Disables own account' do
given 'I am logged in as Bob' do
sign_in_as @user
end
when 'I go to my account page' do
visit account_path(@user)
end
when 'I click on the button to disable my account' do
click_button 'Disable my account'
end
then 'I should see the message that I am logged out' do
within '.flash-messages' do
should_see 'You have been logged out. We will miss you.'
end
end
end
end
The output would contain something like this:
Given I am logged in as Bob
When I go to my account page
And I click on the button to disable my account
Then I should see the message that I am logged out
expected page to contain 'You have been logged out. We will miss you.' but
it did not
+1