Zależy co masz na myśli przez "dużo". Zakładając że każdy test coś tam zapisuje do bazy to również blokuje IO. Na pewno nie mam tam jakiś skomplikowanych obliczeń, które potrzebują dużo CPU.
no mam namyśli właśnie to :) w standardowych JPA / JDBC każde zapytanie to blokujące IO
Docker z bazą działa cały czas. Po każdym teście czyszczę bazę z danych, z której korzystał dany test.
A powiedz mi jaką masz bazę i jak ją czyścisz?
Bo w moim przypadku jak właśnie przerzucałem testy z H2 na Postgres to winowajcą pierwszego mocnego spowolnienia był sposób czyszczenia, truncate w H2 był natychmiastowy, a w postgres powodował vacuum, który spowalniał każdy test o 1-2 sec
Co to znaczy dobry czas testu? Średnio wychodzi mi 0.125 s na test. W tej średniej zawiera się również zmarnowany czas na build itp.
Ciężko porównać z projektu na projekt. U mnie miałem porównanie bo przechodziliśmy z H2 do testów na Postgres (naszą silnik stosowany też na produkcyji).
Pierwsze podejście spowodowało że kilkaset testów co trwało na H2 ~10 min zaczęło trwać ponad 1h.
- każdy test uruchamia się na swojej schemie o nazwie jakas_apka_id_joba_ci
Czy oddzielne schemy w Twoim przypadku dały lepsze czasy niż oddzielne bazy (na jednym serwerze)?
Na pewno schemy są nieco lżejsze bo przynajmniej w postgres oddzielna baza per test wymagała by stawiania pod każdy test nowej puli połączeń po stronie apki i nowego folderu z plikami bazy po strony postgres.
Ale to jest mocno zależne od tego jaką bazę stosujesz i jak Twoja apka zarządza połączeniami.
- baza ma konfiguracje zoptymalizowaną pod testy (RAM disk, nie czekania na zapis WAL'a, itp.)
Myślałem nad sprawdzeniem RAM disk. Dużo to daje? Ogólnie po zoptymalizowaniu bazy ile zyskałeś na czasie?
Pod względem dostępu do dysku najwięcej dało w Postgres wyłączenie czekania na wpadnięcie WAL'a na dysk przed commit <- tylko pamiętaj żeby tego nie włączyć czasem na produkcji ;)
Po tym RAM disk już dał bardzo małe % uzysku. Ale nie wiem jak na Twojej bazie to będzie.