가드가 실행 중일 때 capybara 이상 동작을하는 Rspec

Question

rspec + capybara를 사용하여 몇 가지 테스트를 만들었습니다. 내가 그들 모두가

git:(master) ✗ rspec  
Rack::File headers parameter replaces cache_control after Rack 1.5. 
WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
.WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
.WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
.WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
.WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
.WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
.WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
.WARNING: there is already a transaction in progress 
NOTICE: there is no transaction in progress 
. 

Finished in 32.54 seconds 
8 examples, 0 failures 

통과 RSpec에 그들을 실행하지만 난 가드를 사용하는 경우 일부가 실패하는 경향이있다 (일부 테스트가 실패 할 수 있으며, 시간 수 없음에서 시간)
Guard output

tests code

이 동작을 어떻게 설명 할 수 있습니까? 어떻게 수정 될 수 있습니까?

업데이트 이미이 설정으로 gem 'database_cleaner'을 사용하고 1
:

config.before(:suite) do 
    DatabaseCleaner.strategy = :transaction 
    DatabaseCleaner.clean_with(:transaction) 
    end 

    config.before(:each) do 
    DatabaseCleaner.start 
    end 

    config.after(:each) do 
    DatabaseCleaner.clean 
    end 
    # If you're not using ActiveRecord, or you'd prefer not to run each of your 
    # examples within a transaction, remove the following line or assign false 
    # instead of true. 
    config.use_transactional_fixtures = :transaction 
    config.use_transactional_examples = true 

업데이트 2
가에 따라 파일 https://github.com/Asmmund/notes/commit/a5e0a43d6247bb8f937fb7e9dcc8d8cfa7bfc4ea

Answer 1

의 변경된 몇 당신이 작성한 방법 테스트에서 Capybara는 Selenium 드라이버를 사용하여 실행합니다. Selenium은 트랜잭션 픽스처와 호환되지 않으므로 false로 설정해야합니다.

일반적으로 Capybara (또는 대부분의 통합 테스트)와 함께 Fixtures를 사용하지 않는 것이 좋습니다. 좋은 통합 테스트는 설비에 최소한 의존해야하며 엔드 투 엔드 흐름에서 데이터를 생성해야합니다 (예 : 사용자 계정은 시뮬레이션 된 인앱 조치로 생성되어야합니다. 즉, 테스트는 Capybara를 사용하여 가입 양식을 제출해야합니다). 그러나 홀수의 경우는 피할 수 없으며 DB에 데이터를 입력해야 할 수도 있습니다. 많은 사람들이 성공을 위해 FactoryGirl과 같은 공장을 사용합니다.

테스트가 셀레늄 인 경우 DB 정리도 트랜잭션, 전략이 아닌 자르기를 사용해야합니다.

이 자습서를 더 자세히 살펴보십시오.

참고 :있는 동안 그들이해야하지, 일부 레코드가 테스트 데이터베이스에 지속 어쩌면

http://asciicasts.com/episodes/257-request-specs-and-capybara