|
4 | 4 | # instead of editing this one. Cucumber will automatically load all features/**/*.rb |
5 | 5 | # files. |
6 | 6 |
|
7 | | -require 'rubygems' |
8 | | -require 'spork' |
9 | | - |
10 | | -Spork.prefork do |
11 | | - require 'cucumber/rails' |
12 | | - |
13 | | - |
14 | | - # Capybara defaults to XPath selectors rather than Webrat's default of CSS3. In |
15 | | - # order to ease the transition to Capybara we set the default here. If you'd |
16 | | - # prefer to use XPath just remove this line and adjust any selectors in your |
17 | | - # steps to use the XPath syntax. |
18 | | - Capybara.default_selector = :css |
19 | | - |
| 7 | +require 'cucumber/rails' |
| 8 | + |
| 9 | +# Capybara defaults to XPath selectors rather than Webrat's default of CSS3. In |
| 10 | +# order to ease the transition to Capybara we set the default here. If you'd |
| 11 | +# prefer to use XPath just remove this line and adjust any selectors in your |
| 12 | +# steps to use the XPath syntax. |
| 13 | +Capybara.default_selector = :css |
| 14 | + |
| 15 | +# By default, any exception happening in your Rails application will bubble up |
| 16 | +# to Cucumber so that your scenario will fail. This is a different from how |
| 17 | +# your application behaves in the production environment, where an error page will |
| 18 | +# be rendered instead. |
| 19 | +# |
| 20 | +# Sometimes we want to override this default behaviour and allow Rails to rescue |
| 21 | +# exceptions and display an error page (just like when the app is running in production). |
| 22 | +# Typical scenarios where you want to do this is when you test your error pages. |
| 23 | +# There are two ways to allow Rails to rescue exceptions: |
| 24 | +# |
| 25 | +# 1) Tag your scenario (or feature) with @allow-rescue |
| 26 | +# |
| 27 | +# 2) Set the value below to true. Beware that doing this globally is not |
| 28 | +# recommended as it will mask a lot of errors for you! |
| 29 | +# |
| 30 | +ActionController::Base.allow_rescue = false |
| 31 | + |
| 32 | +# Remove/comment out the lines below if your app doesn't have a database. |
| 33 | +# For some databases (like MongoDB and CouchDB) you may need to use :truncation instead. |
| 34 | +begin |
| 35 | + DatabaseCleaner.strategy = :transaction |
| 36 | +rescue NameError |
| 37 | + raise "You need to add database_cleaner to your Gemfile (in the :test group) if you wish to use it." |
20 | 38 | end |
21 | 39 |
|
22 | | -Spork.each_run do |
23 | | - # By default, any exception happening in your Rails application will bubble up |
24 | | - # to Cucumber so that your scenario will fail. This is a different from how |
25 | | - # your application behaves in the production environment, where an error page will |
26 | | - # be rendered instead. |
27 | | - # |
28 | | - # Sometimes we want to override this default behaviour and allow Rails to rescue |
29 | | - # exceptions and display an error page (just like when the app is running in production). |
30 | | - # Typical scenarios where you want to do this is when you test your error pages. |
31 | | - # There are two ways to allow Rails to rescue exceptions: |
32 | | - # |
33 | | - # 1) Tag your scenario (or feature) with @allow-rescue |
34 | | - # |
35 | | - # 2) Set the value below to true. Beware that doing this globally is not |
36 | | - # recommended as it will mask a lot of errors for you! |
37 | | - # |
38 | | - ActionController::Base.allow_rescue = false |
| 40 | +# You may also want to configure DatabaseCleaner to use different strategies for certain features and scenarios. |
| 41 | +# See the DatabaseCleaner documentation for details. Example: |
| 42 | +# |
| 43 | +# Before('@no-txn,@selenium,@culerity,@celerity,@javascript') do |
| 44 | +# DatabaseCleaner.strategy = :truncation, {:except => %w[widgets]} |
| 45 | +# end |
| 46 | +# |
| 47 | +# Before('~@no-txn', '~@selenium', '~@culerity', '~@celerity', '~@javascript') do |
| 48 | +# DatabaseCleaner.strategy = :transaction |
| 49 | +# end |
| 50 | +# |
| 51 | + |
| 52 | +# Possible values are :truncation and :transaction |
| 53 | +# The :transaction strategy is faster, but might give you threading problems. |
| 54 | +# See https://github.com/cucumber/cucumber-rails/blob/master/features/choose_javascript_database_strategy.feature |
| 55 | +Cucumber::Rails::Database.javascript_strategy = :truncation |
39 | 56 |
|
40 | | - # Remove/comment out the lines below if your app doesn't have a database. |
41 | | - # For some databases (like MongoDB and CouchDB) you may need to use :truncation instead. |
42 | | - begin |
43 | | - DatabaseCleaner.strategy = :transaction |
44 | | - rescue NameError |
45 | | - raise "You need to add database_cleaner to your Gemfile (in the :test group) if you wish to use it." |
46 | | - end |
47 | | - |
48 | | - # You may also want to configure DatabaseCleaner to use different strategies for certain features and scenarios. |
49 | | - # See the DatabaseCleaner documentation for details. Example: |
50 | | - # |
51 | | - # Before('@no-txn,@selenium,@culerity,@celerity,@javascript') do |
52 | | - # DatabaseCleaner.strategy = :truncation, {except: %w[widgets]} |
53 | | - # end |
54 | | - # |
55 | | - # Before('~@no-txn', '~@selenium', '~@culerity', '~@celerity', '~@javascript') do |
56 | | - # DatabaseCleaner.strategy = :transaction |
57 | | - # end |
58 | | - # |
59 | | - |
60 | | - # Possible values are :truncation and :transaction |
61 | | - # The :transaction strategy is faster, but might give you threading problems. |
62 | | - # See https://github.com/cucumber/cucumber-rails/blob/master/features/choose_javascript_database_strategy.feature |
63 | | - Cucumber::Rails::Database.javascript_strategy = :truncation |
64 | | - |
65 | | -end |
0 commit comments