2013-02-17 14 views
6

unbegrenzt. Ich führe meine Spezifikationen durch parallel_tests auf dem Capybara-webkit Treiber. Ich habe folgende Rubin Umgebung.Paralleltestausführung hängt auf Webkit-Treiber für rspec

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

Laufen durch rvm auf einem gemset, die die folgenden (gekürzt für Capybara enthält, Schienen, rspec und parallel_tests für Relevanz, wenn eine größere Schneise meiner gemset sehen würde helfen, bitte lassen Sie mich wissen):

*** LOCAL GEMS *** 

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

Wenn ich meinen Test-Anzug auf einem einzigen Prozess mit rake spec laufen, alle meine Tests vollständig ausgeführt. Wenn jedoch durch parallel_tests runnning, geschieht Folgendes:

8 processes for 220 specs, ~ 27 specs per process 

Wonach die Prozesse startet schließlich Rückwegs:

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

Aber nach den ersten 6 Prozesse zurückkommen, werden parallel_spec hängen auf unbestimmte Zeit, nie beenden und nie Ausgabe für die verbleibenden 2 Prozesse drucken.

Ich bin auf einem MacBook Pro mit OS X Lion, mit einem 2,4 GHz Intel i7.

Also meine Frage ist einfach: Warum hängt es, wie kann ich debuggen, warum es hängt, und wie kann ich aufhören zu hängen und erlauben parallel_tests zu Ende ausgeführt werden?

+1

Haben Sie jemals eine Lösung gefunden? Ich stoße auf das gleiche Problem. – blim8183

+0

Dito. Ich habe parallel_tests und Bundler vergeblich verbessert. Rätselhaft. – annalogarhythm

+0

Was ist, wenn Sie es zurück auf 6 skalieren? Ich wundere mich, wenn Sie unbeabsichtigt Ihren Datenbankserver oder etwas ersticken. –

Antwort

1

Es fehlen Informationen bezüglich Ihrer RSPEC-Konfiguration und Bibliotheksnutzung, auf die Sie wahrscheinlich eine Antwort erhalten würden. Allerdings habe ich in einer Umgebung mit mehreren Threads ein ähnliches Verhalten beobachtet, wenn ich rspec für die Integration-Spezifikationen ausführe.

Der Hinweis auf https://github.com/grosser/parallel_tests/wiki scheint irreführend in Bezug auf die Integration Spezifikationen. Der Versuch, sich auf die transaction-Strategie von DatabaseCleaner oder use_transactional_fixtures zu verlassen, führt garantiert zu Deadlocks für alle nicht blockierenden Datenbankadapter.

Capybara spinnt mehrere Threads für die Integration Spezifikationen. Wenn die Client- und Server-Threads gleichzeitig mit denselben Datensätzen interagieren, kommt es häufig zu Timeouts oder Deadlocks. Gelegentlich kann der Deadlock dazu führen, dass Ihre Suite dauerhaft ausgeführt wird, bis sie manuell beendet wird.

Die stabilste Konfiguration, die ich gefunden habe, um dies zu verhindern, ist eine Kombination aus dem Teilen der Verbindung zwischen Instanzen und vernünftige Verwendung von 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 
+0

Danke für die ausführliche und lange Antwort. Leider behebt es das Problem nicht wirklich. –

+0

Tut mir leid das zu hören. Die parallel_tests Anweisungen über Integration Spezifikationen schien wie der wahrscheinlichste Täter. –