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.