it is an established convention to put all your rails tests or specifications in the
cucumber features on the other hand go in the
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
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.
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.