7

capybara-webkit ドライバーで parallel_tests を使用してスペックを実行しています。次のルビー環境があります。

 ruby -v
 ruby 1.9.3p125 (2012-02-16 revision 34643) [x86_64-darwin11.4.2]

以下を含むgemsetでrvmを実行します（関連性のためにカピバラ、レール、rspec、およびparallel_testsのために切り捨てられています。私のgemsetのより大きな帯が役立つ場合は、お知らせください）：

 *** LOCAL GEMS ***

 ...
 capybara (1.1.2)
 parallel_tests (0.8.12)
 rails (3.2.11)
 rspec (2.11.0)

を使用して単一のプロセスでテスト スーツを実行するとrake spec、すべてのテストが実行されて完了します。ただし、parallel_tests を実行すると、次のことが起こります。

 8 processes for 220 specs, ~ 27 specs per process

その後、プロセスは最終的に戻ってきます。

 Finished in 11 minutes 15.76 seconds
 Finished in 11 minutes 28.89 seconds

ただし、最初の 6 つのプロセスが戻った後、parallel_spec は無期限にハングし、終了せず、残りの 2 つのプロセスの出力を出力しません。

私は、2.4 GHz Intel i7 を搭載した OS X Lion を実行している MacBook Pro を使用しています。

だから私の質問は簡単です:なぜそれがぶら下がっているのですか?なぜそれがぶら下がっているのかをデバッグするにはどうすればよいですか?

4

2 に答える 2

2

rspec の構成とライブラリの使用に関して、いくつかの情報が欠落しており、おそらくこれに対する回答が得られるでしょう。そうは言っても、統合仕様の rspec を実行しているときに、マルチスレッド環境で同様の動作を見たことがあります。

https://github.com/grosser/parallel_tests/wikiにあるアドバイスは、統合仕様に関して誤解を招くようです。またはのtransaction戦略に依存しようとすると、ノンブロッキング データベース アダプタでデッドロックが発生することが保証されています。DatabaseCleaneruse_transactional_fixtures

Capybara は、統合仕様のために複数のスレッドをスピンアップします。クライアント スレッドとサーバー スレッドが同時に同じレコードと対話しようとすると、タイムアウトやデッドロックが発生することがよくあります。デッドロックにより、スイートの実行が手動で強制終了されるまで永久にハングすることがあります。

これを防ぐために私が見つけた最も堅実な構成は、ActiveRecordインスタンス間の接続の共有と の賢明な使用の組み合わせですDatabaseCleaner。

# integration_spec_helper.rb

RSpec.configure do |config|
  config.use_transactional_fixtures = false

  class ActiveRecord::Base
    class_attribute :shared_connection

    def self.connection
      self.shared_connection || retrieve_connection
    end
  end

  config.before do |example|
    ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection

    if Capybara.current_driver == :webkit
      DatabaseCleaner.strategy = :deletion
    else
      DatabaseCleaner.strategy = :transaction
    end

    DatabaseCleaner.start
  end

  config.after do
    DatabaseCleaner.clean
  end
end
于 2013-06-10T14:29:28.573 に答える