3 ms·
Not a fan of cucumber. I started it, but the extra layer of abstraction was too much complexity for too little benefit. Instead, I think you can make almost as
by losvedir 13y ago
Not a fan of cucumber. I started it, but the extra layer of abstraction was too much complexity for too little benefit. Instead, I think you can make almost as easy to read and understand acceptance tests with plain old rspec.
I just TDD'ly implemented a "user signs up for Direct Deposit" feature, and the acceptance tests look like this:
describe 'Direct Deposit' do
before do
@workflow = DirectDepositWorkflow.new(create(:user))
end
describe 'User sets up direct deposit with correct info.', :js do
it 'user sees confirmation page - individual' do
@workflow.sign_in_and_visit_direct_deposit_form
@workflow.submit_correct_form
expect(@workflow).to have_confirmation_message
end
...
end
end
Then you can make the workflow spec helper class:
class DirectDepositWorkflow < Struct.new(:user)
include Capybara::DSL
include UtilitiesHelper
include Rails.application.routes.url_helpers
def sign_in_and_visit_direct_deposit_form
...
end
def submit_correct_form
fill_in 'name', with: 'John'
click_button 'Submit'
end
def has_confirmation_message?
page.has_css? '.success_alert', I18n.t(...)
end
end
To me, this is the perfect blend of easy to read, high level specs (serving the rule of cucumber/gherkin), with easy to understand, rspec syntax and ordinary method definitions.
- karmajunkie 13y agoInteresting technique—I'm still a fan of Gherkin in concept (though I don't use it right now) but I do the same kind of testing in Rspec. My variation isn't quite as refined as your workflow though; i'm just defining methods in the describe block. It has (what i perceive as) an advantage in that the scenarios don't hit any instance variables so they're a bit more readable, but i like the way you're doing that.