2013-02-17 25 views
6

Używam mojej specyfikacji poprzez testy parallel_tests w sterowniku capybara-webkit. Mam następujący rubinowy środowiska.Równoległe wykonywanie testów zawiesza się w nieskończoność na sterowniku Webkit dla rspec

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

przebiegającej przez RVM na gemset który zawiera następujące (obcięty do kapibary, szyny, RSpec i parallel_tests na znaczenie Jeśli widząc większy skrawek mojego gemset pomoże, proszę daj mi znać):

*** LOCAL GEMS *** 

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

Kiedy uruchomić mój garnitur testową na jednym procesie z rake spec, wszystkich moich testów uruchomić do końca. Jednak, gdy uruchomiona przez parallel_tests dodaje się dzieje:

8 processes for 220 specs, ~ 27 specs per process 

czym procesów w końcu zacząć wracać:

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

Ale, po pierwsze 6 procesy wrócić, parallel_spec zawiśnie na czas nieokreślony, nigdy nie kończ i nigdy nie drukuj danych wyjściowych dla pozostałych 2 procesów.

Jestem na MacBooku Pro z systemem OS X Lion, z procesorem Intel i7 2,4 GHz.

Moje pytanie jest proste: dlaczego to się kręci, jak mogę debugować, dlaczego jest zawieszone, i jak mogę go powstrzymać przed zawieszeniem i zezwoleniem na uruchamianie testów równoległych do ukończenia?

+1

Czy kiedykolwiek znalazłeś rozwiązanie tego problemu? Występuję w tym samym problemie. – blim8183

+0

Ditto. Uaktualniłem testy parallel_tests i bundler bez rezultatu. Zastanawiające. – annalogarhythm

+0

Co się stanie, jeśli wrócisz do 6? Zastanawiam się, czy przypadkowo dusisz swój serwer bazy danych, czy coś ... –

Odpowiedz

1

Brakuje niektórych informacji dotyczących konfiguracji rspec i użycia biblioteki, które prawdopodobnie zapewnią odpowiedź na to pytanie. To powiedziawszy, widziałem podobne zachowanie w środowisku wielowątkowym podczas uruchamiania rspec dla specyfikacji integracji.

Porady na temat https://github.com/grosser/parallel_tests/wiki wydają się wprowadzać w błąd w odniesieniu do specyfikacji integracji. Próba polegania na strategii transaction z DatabaseCleaner lub use_transactional_fixtures gwarantuje uzyskanie zakleszczeń dla każdego nieblokującego adaptera bazy danych.

Capybara obraca wiele wątków dla specyfikacji integracji. Gdy wątek klienta i serwera podejmuje próbę interakcji z tymi samymi rekordami w tym samym czasie, często kończy się to przekroczeniami czasu lub zakleszczeniami. Czasami impas może spowodować, że pakiet będzie zawieszony na stałe, dopóki nie zostanie zabity ręcznie.

Najbardziej stabilna konfiguracja, którą znalazłem, aby temu zapobiec, jest połączeniem dzielenia połączenia między instancjami ActiveRecord i rozsądnego korzystania z 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

Dzięki za szczegółową i długą odpowiedź. Niestety, tak naprawdę nie naprawia problemu. –

+0

Przykro nam to słyszeć. Instrukcje parallel_tests dotyczące specyfikacji integracji wydawały się najbardziej prawdopodobnym winowajcą. –