Przyspieszenie testów RSpec w dużej aplikacji Railsowej

Mam aplikację Railsową z ponad 2000 przykładów w moich testach RSpec. Nie trzeba dodawać, że jest to duża aplikacja i jest wiele do przetestowania. Uruchamianie tych testów w tym momencie jest bardzo nieefektywne, a ponieważ trwa to tak długo, jesteśmy prawie na etapie zniechęcenia do ich pisania przed wypchnięciem nowej kompilacji. Dodałem --profile do moich specyfikacji. Pozwala znaleźć najdłużej działające przykłady i jest co najmniej 10 z nich, których uruchomienie zajmuje średnio 10 sekund. Czy to normalne wśród ekspertów RSpec? Czy w jednym przykładzie 10 sekund jest zbyt długie? Zdaję sobie sprawę, że w przypadku 2000 przykładów dokładne przetestowanie wszystkiego zajmie niebanalną ilość czasu - ale w tym momencie 4 godziny to trochę śmieszne.

Jakie czasy widzisz dla swoich najdłużej działających przykładów? Co mogę zrobić, aby rozwiązać problemy z istniejącymi specyfikacjami, aby znaleźć wąskie gardła i przyspieszyć działanie. W tym momencie każda minuta naprawdę pomogłaby.

10 sekund to bardzo długi czas na wykonanie pojedynczego testu. Moje przeczucie jest takie, że Twój cel specyfikacji przeprowadza jednocześnie testy jednostkowe i testy integracji. Jest to typowa rzecz, w którą wpadają projekty i na pewnym etapie będziesz musiał pokonać ten dług techniczny, jeśli chcesz produkować więcej i szybciej. Istnieje wiele strategii, które mogą ci w tym pomóc ... a ja polecę kilka z nich, z których korzystałem w przeszłości.

1. Oddzielna jednostka od testów integracji

Pierwszą rzeczą, którą bym zrobił, to oddzielenie jednostki od testów integracyjnych. Możesz to zrobić:

1. Przenoszenie ich (do oddzielnych folderów w katalogu spec) - i modyfikowanie celów rake
2. Oznaczanie ich (rspec umożliwia tagowanie testów)

Filozofia głosi, że chcesz, aby twoje regularne kompilacje były szybkie - w przeciwnym razie ludzie nie będą zbyt szczęśliwi, aby je często uruchamiać. Więc wracaj na to terytorium. Skorzystaj z szybkiego uruchamiania regularnych testów i używaj serwera ciągłej integracji, aby uruchomić bardziej kompletną kompilację.

Test integracji to test obejmujący zewnętrzne zależności (np. Baza danych, usługa sieciowa, kolejka, a niektórzy twierdzą, że system plików). Test jednostkowy po prostu testuje określony element kodu, który chcesz sprawdzić. Powinien działać szybko (możliwe jest 9000 w 45 sekund), tj. Większość z nich powinna działać w pamięci.

2. Przekształć testy integracji w testy jednostkowe

Jeśli większość testów jednostkowych jest mniejsza niż zestaw testów integracyjnych, masz problem. Oznacza to, że niespójności zaczną pojawiać się łatwiej. Od tego momentu zacznij tworzyć więcej testów jednostkowych, aby zastąpić testy integracyjne. Możesz pomóc w tym procesie:

1. Użyj fałszywego frameworka zamiast prawdziwego zasobu. Rspec ma wbudowany framework do mockowania.
2. Uruchom rcov na swoim zestawie testów jednostkowych. Użyj tego, aby ocenić, jak dokładny jest twój zestaw testów jednostkowych.

Gdy masz już odpowiednie testy jednostkowe, które zastąpią test integracji - usuń test integracji. Podwójne testowanie tylko pogarsza konserwację.

3. Nie używaj urządzeń

Urządzenia są złe. Zamiast tego użyj fabryki (mechanika lub robota fabrycznego). Systemy te mogą budować bardziej adaptowalne wykresy danych, a co ważniejsze, mogą budować obiekty w pamięci, których możesz używać, zamiast ładować rzeczy z zewnętrznego źródła danych.

4. Dodaj kontrole, aby powstrzymać testy jednostkowe jako testy integracji

Teraz, gdy masz już szybsze testy, czas na sprawdzenie, aby to ZATRZYMAĆ.

Istnieją biblioteki, które małpa poprawiają rekord aktywny, aby zgłosić błąd podczas próby uzyskania dostępu do bazy danych (UnitRecord).

Możesz także spróbować parowania i TDD, które mogą zmusić Twój zespół do pisania szybszych testów, ponieważ:

1. Ktoś sprawdza - żeby nikt nie był leniwy
2. Właściwe TDD wymaga szybkiej informacji zwrotnej. Powolne testy sprawiają, że cała sprawa jest bolesna.

5. Użyj innych bibliotek, aby rozwiązać problem

Ktoś wspomniał o spork (przyspiesza ładowanie zestawu testów pod szynami3), hydra / parallel_tests - aby uruchomić testy jednostkowe równolegle (na wielu rdzeniach).

Prawdopodobnie powinno to być używane OSTATNIE. Twój prawdziwy problem pojawia się w kroku 1, 2, 3. Rozwiąż go, a będziesz w lepszej pozycji do odgrywania dodatkowej infrastruktury.

Aby uzyskać świetną książkę kucharską na temat poprawy wydajności zestawu testów, zapoznaj się z prezentacją Grease Your Suite .

Dokumentuje 45-krotne przyspieszenie w czasie wykonywania zestawu testów, wykorzystując takie techniki, jak:

• fast_context
• quickerclip
• hydra
• przerażające poprawki systemu plików
• tcmalloc
• Strojenie GC w Ruby Enterprise Edition

Możesz użyć Spork. Obsługuje 2.3.x,

https://github.com/sporkrb/spork

lub ./script/spec_server, który może działać w wersji 2.x

Możesz także edytować konfigurację bazy danych (co zasadniczo przyspiesza zapytania do bazy danych itp.), Co również zwiększy wydajność testów.

10 sekund na przykład wydaje się bardzo długim czasem. Nigdy nie widziałem specyfikacji, która zajmowała więcej niż jedną sekundę, a większość zajmuje znacznie mniej. Czy testujesz połączenia sieciowe? Baza danych pisze? System plików pisze?

Używaj makiet i kodów pośredniczących tak często, jak to możliwe - są one znacznie szybsze niż pisanie kodu, który trafia do bazy danych. Niestety kpiny i klepanie również zajmuje więcej czasu (i jest trudniejsze do wykonania poprawnie). Musisz zrównoważyć czas spędzony na pisaniu testów z czasem spędzonym na wykonywaniu testów.

Po drugie, wypowiedź Andrew Grimma na temat przyjrzenia się systemowi CI, który może pozwolić na zrównoleglenie zestawu testów. Dla czegoś tej wielkości może to być jedyne realne rozwiązanie.

Kilka osób wspomniało powyżej o Hydrze. W przeszłości używaliśmy go z dużym powodzeniem. Niedawno udokumentowałem proces uruchomienia i uruchomienia hydry: http://logicalfriday.com/2011/05/18/faster-rails-tests-with-hydra/

Zgodziłbym się z opinią, że tego rodzaju technika nie powinna zastępować pisania testów, które domyślnie mają dobrą strukturę i są szybkie.

Jeśli używasz modeli ActiveRecord, powinieneś również wziąć pod uwagę koszt szyfrowania BCrypt.

Możesz przeczytać więcej na ten temat w tym poście na blogu: http://blog.syncopelabs.co.uk/2012/12/speed-up-rspec-test.html

Klejnot szybszego_zbierania się może ci pomóc Poza tym jedynym sposobem jest (tak jak to zrobiłeś) profilowanie i optymalizacja lub używanie spork lub czegoś, co równolegle uruchamia twoje specyfikacje. http://ruby-toolbox.com/categories/distributed_testing.html

Możesz skorzystać z kilku prostych wskazówek, aby najpierw zbadać, gdzie spędza się większość czasu, jeśli jeszcze ich nie wypróbowałeś. Spójrz na poniższy artykuł:

https://blog.mavenhive.in/7-tips-to-speed-up-your-webdriver-tests-4f4d043ad581

Myślę, że większość z nich to ogólne kroki, które można by zastosować niezależnie od narzędzia używanego do testowania.

Usuń istniejący zestaw testów. Będzie niesamowicie skuteczny.