public
Last active

don't put all your stuff in /spec

  • Download Gist
acceptance_spec_helper.rb
Ruby
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
require 'simplecov'
SimpleCov.command_name "acceptance"
 
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'rspec/autorun'
 
require 'capybara/rails'
require 'capybara/poltergeist'
Capybara.javascript_driver = :poltergeist
Capybara.always_include_port = true
 
Dir[Rails.root.join("acceptance/support/**/*.rb")].each { |f| require f }
 
ActiveRecord::Migration.check_pending!
 
RSpec.configure do |config|
config.use_transactional_fixtures = false
config.order = "default"
 
config.before(:all) do
Capybara.default_host = 'testhost.com'
Capybara.app_host = 'testhost.com'
DatabaseCleaner.clean_with :truncation
generate_fixtures
end
 
config.before(:each) do
if example.metadata[:js] # some poltergeist specifics
Capybara.current_session.driver.add_header('Referer', 'some.host.com')
end
end
 
# acceptance helpers
config.include FixtureGenerator
config.include WidgetPathHelper
config.include AuthenticationHelper
end
readme.md
Markdown

it is an established convention to put all your rails tests or specifications in the test/spec folder. even jasmine javascript files go in spec/javascripts!?

cucumber features on the other hand go in the features folder.

i don't like cucumber, because of the additonal complexity that comes with the gherkin langauge, but i like the idea that they think about features to be something different.

when writing acceptance tests i put them in the acceptance folder and add a custom spec_helper file that is usually called acceptance_spec_helper.rb as rpsec runners get confused with multiple spec_helper.rb files.

acceptance tests and normal rails tests have orthogonal requirements that should be expressed in using different setups.

i like to have use_transactional_fixtures and random test execution turned on for normal rails tests, because it's super fast and each spec should be independend of other tests.

it's different when writing acceptance specifications with capybara and some headless browser that spawn a real rails process to run arbitrary JavaScript code within.

those processes have a basic problem when it comes to database queries. changes in one process/thread might not be seen in another one because of transaction visibility. this is often times hard to debug and mindboggling. there are some hacks to get rid of this problem by sharing the same database connection, but they introduce other problemes, mostly race conditions.

long story short, i like to turn use_transactional_fixtures of and use fixtures (or hardcoded factory data) for running acceptance tests, as this fits more into the idea of acceptance tests. if you combine this approach with stateful page-objects, than you can write pretty readable tests like LoginPage.new.login(:uschi). In this case, there is some fixture data with a user called Uschi.

I like to run DatabaseCleaner between each group of specs and recreate the fixtures, so they are fresh for each capybara spec file. This setup comes pretty close to how cucmber does it, without all the cucumber-world crazyness.

Some benefits that come with this approach:

  • faster spec runs for both suites
  • easy to separate out suites for CI
  • great for coverage reports
  • simple spec_helpers
  • separation of concerns via custom test modules

See the example configurations for more details.

spec_helper.rb
Ruby
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
require 'simplecov'
 
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'rspec/autorun'
 
Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }
 
ActiveRecord::Migration.check_pending!
 
RSpec.configure do |config|
config.use_transactional_fixtures = true
config.order = "random"
 
config.before(:each, type: :request) do
host!('testhost.com')
end
 
config.include AuthenticationHelper, type: :controller
end

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.