Historia
Framework testowy Go wprowadził t.Parallel(), aby zaradzić rosnącemu czasowi trwania pipeline'ów CI w dużych bazach kodu. Przed powszechnym wdrożeniem procesorów wielordzeniowych testy domyślnie uruchamiano sekwencyjnie. W miarę rozwoju projektów do tysięcy testów, czysto sekwencyjne wykonanie stało się wąskim gardłem, ale nieograniczony równoległość groziłby wyczerpaniem zasobów procesów, takich jak deskryptory plików czy połączenia z bazą danych. Celem projektowania było zapewnienie wbudowanego, opcjonalnego modelu współbieżności, który szanowałby globalny limit bez wymagania od programistów ręcznej orchestracji pul roboczych lub złożonej synchronizacji dla każdej suite testowej.
Problem
Kiedy programista wywołuje t.Parallel(), test musi zakomunikować uruchomieniu, że może przebiegać równolegle z innymi testami. Jednak framework musi egzekwować ścisły limit współbieżności (domyślnie ustawiony na GOMAXPROCS, ale konfigurowalny za pomocą flagi -parallel), aby zapobiec głodzeniu zasobów. Problem zaostrza się w przypadku zagnieżdżonych podtestów: test nadrzędny może wywołać t.Run wielokrotnie, a każdy podtest może niezależnie wywołać t.Parallel(). Rozwiązanie musi zapobiec zwolnieniu slotu wykonania przez rodzica przed ukończeniem wszystkich jego potomków, zapewniając jednocześnie, że głęboko zagnieżdżone równoległe podtesty poprawnie przejmują sloty z tej samej globalnej puli bez zakleszczenia rodzica lub przekroczenia limitu.
Rozwiązanie
Pakiet testing wykorzystuje semafor implementowany jako buforowany kanał pustych struktur (chan struct{}) rozmiaru odpowiadającego wartości flagi -parallel. Ten kanał jest współdzielony między wszystkimi testami w pakiecie. Każda instancja T przechowuje odniesienie do tego kanału parallel i wewnętrznego kanału signal do koordynacji z rodzicem.
Kiedy wywoływane jest t.Parallel():
signal, odblokowując wywołanie rodzica t.Run, aby rodzic mógł kontynuować lub zakończyć, podczas gdy podtest będzie uruchamiany równolegle.parallel, przejmując slot wykonania.parallel, gdy funkcja testowa zwraca, a wszystkie haki t.Cleanup są wykonywane.Dla hierarchii, t.Run blokuje rodzica gorutyny przy użyciu sync.WaitGroup, aż podtest całkowicie się zakończy, nawet jeśli podtest działa równolegle. To zapewnia, że rodzic trzyma swój slot (lub czeka), aż całe drzewo podtestów zakończy się, zapobiegając przekroczeniu globalnego limitu przez wybuch głęboko zagnieżdżonych równoległych testów.
// Model koncepcyjny wewnętrznych mechanizmów pakietu testing type T struct { parallel chan struct{} // Wspólny semafor signal chan struct{} // Informuje rodzica, że Parallel() zostało wywołane parent *T wg sync.WaitGroup // Czeka na podtesty } func (t *T) Parallel() { // Zwolnij rodzica do kontynuowania close(t.signal) // Przejęcie slotu z globalnej puli t.parallel <- struct{}{} // Cleanup zwalnia slot, gdy test kończy się t.Cleanup(func() { <-t.parallel }) } func (t *T) Run(name string, f func(t *T)) bool { t.wg.Add(1) sub := &T{parallel: t.parallel, signal: make(chan struct{})} go func() { defer t.wg.Done() f(sub) }() <-sub.signal // Czeka na rozpoczęcie podtestu lub wywołanie Parallel t.wg.Wait() // Czeka na zakończenie return !sub.Failed() }
Kontekst
Zespół platformowy utrzymywał monorepo zawierające 2,000 testów integracyjnych dla architektury mikroserwisów. Każdy test uruchamiał ephemeralne kontenery Docker dla Postgres i Redis. Uruchamianie testów sekwencyjnie zajmowało 45 minut, co uniemożliwiało szybkie uzyskiwanie informacji zwrotnej. Jednak wykonanie go test -parallel 100 spowodowało wyczerpanie limitu max_user_namespaces jądra, co doprowadziło do awarii hosta i uszkodzenia pamięci podręcznej kompilacji.
Problem
Zespół musiał ograniczyć intensywne testy kontenerów do pięciu aktywnych instancji, aby uszanować limity jądra, a jednocześnie pozwolić czystym testom jednostkowym na uruchomienie z -parallel 32 dla maksymalnej wydajności. Standardowy pakiet testowy Go akceptuje tylko jedną globalną wartość -parallel na wywołanie, nie oferując wbudowanej metody stosowania różnych limitów dla różnych kategorii testów w tym samym uruchomieniu.
Rozważane rozwiązania
Zewnętrzna orchestracja z Bazel.
Proponowano migrację do Bazel, ponieważ obsługuje podział testów i tagowanie zasobów (np. tags = ["resources:postgres:1"]). To pozwoliłoby harmonogramowi precyzyjnie ograniczyć równoległe testy baz danych. Jednak wymagało to przepisania całego systemu budowania i utraty prostoty go test. Krzywa uczenia się była stroma, a lokalne przepływy pracy programistów zmieniłyby się znacznie, spowalniając programistów nieznających języka zapytań Bazel.
Ręczny semafor w ramach suite testowych.
Programiści rozważali dodanie zmiennej na poziomie pakietu var dbSem = make(chan struct{}, 5) i ręczne przypisanie jej w każdym teście integracyjnym na początku. To dało by szczegółową kontrolę, ale wprowadziło porządne szeregowanie i ryzyko zakleszczenia, jeśli test zbudziłby panikę trzymając semafor. Fragmentowało to również model współbieżności — niektóre testy respektowały flagę -parallel, inne respektowały niestandardowy semafor — co utrudniało debugowanie i prowadziło do niespójnej ewidencji zasobów.
Separation tagów budowania z etapami CI.
Zespół zdecydował się na segregację testów przy użyciu tagów budujących. Dodali //go:build integration do wszystkich testów z wykorzystaniem kontenerów, a testy jednostkowe pozostały bez oznaczenia. Pipeline CI najpierw uruchomił go test -short -parallel 32 ./... dla testów jednostkowych, a następnie osobno uruchomił go test -tags=integration -parallel 5 ./.... To wykorzystało istniejące funkcje narzędzi Go, nie modyfikując logiki testu. Minusem było utracenie współbieżności między testami jednostkowymi a integracyjnymi; etapy byly uruchamiane sekwencyjnie. Jednak, ponieważ testy jednostkowe kończyły się w trzy minuty, całkowity czas (3m + 20m) był akceptowalny i stabilny.
Wybrane rozwiązanie i wynik
Wybrali separację tagów budowania. Wymagało to minimalnych zmian w kodzie — jedynie dodania tagów do nagłówków plików — i wykorzystywało naturalnie semafor standardowego pakietu testing bez niestandardowej synchronizacji. CI stało się stabilne, limity jądra były szanowane, a programiści mogli nadal uruchamiać go test -tags=integration -parallel 4 lokalnie w celu debugowania. Całkowity czas CI spadł z 45 minut do 23 minut, a awarie hosta ustały całkowicie.
Dlaczego wywołanie t.Parallel() po uruchomieniu gorutyny czasami skutkuje tym, że ta gorutyna loguje do niewłaściwego wyjścia testu lub panikuje?
Gdy wywoływane jest t.Parallel(), bieżąca gorutyna testowa blokuje się na semaforze, a rodzic kontynuuje z następny testem. Uruchomiona gorutyna jednak dziedziczy instancję T. Jeśli główna funkcja testowa zwróci, podczas gdy gorutyna nadal działa, pakiet testowy oznacza T jako zakończony i zamyka jego bufory wyjściowe. Kolejne wywołania t.Log lub t.Error z orfanowej gorutyny mogą panikować z komunikatem "Log w gorutynie po zakończeniu TestX". Prawidłowe podejście to zsynchronizowanie zakończenia gorutyny za pomocą sync.WaitGroup lub zapewnienie, że t.Cleanup czeka za nią, ponieważ t.Parallel() nie czeka automatycznie na odłączone gorutyny; koordynuje tylko cykl życia funkcji testowej z uruchamiaczem.
Jak pakiet testowy zapobiega zwolnieniu slotu równoległości przez rodzica przed zrealizowaniem wszystkich jego podtestów — niektóre z nich mogą również wywołać t.Parallel() — z zakończeniem?
Struktura T osadza sync.WaitGroup. Gdy wywoływane jest t.Run, aby utworzyć podtest, rodzic wywołuje t.wg.Add(1) przed uruchomieniem gorutyny podtestu, a podtest wywołuje t.wg.Done() w funkcji opóźnionej po zakończeniu. Kluczowe jest to, że gdy sam podtest wywołuje t.Parallel(), natychmiast dekrementuje WaitGroup rodzica (pozwalając rodzicowi potencjalnie zakończyć własne ciało funkcji), ale całkowite zakończenie testu rodzica — a tym samym zwolnienie jego tokenu semafora — jest blokowane przez finalne t.wg.Wait() w obiegu czyszczącym. Tworzy to drzewiastą strukturę oczekiwania, w której główny test równoległy trzyma slot, aż całe drzewo podtestów sekwencyjnych i równoległych zakończy się, zapewniając, że limit -parallel dokładnie odzwierciedla liczbę aktywnych drzew testów, a nie tylko aktywnych gorutyn.
Dlaczego t.Setenv może panikować, jeśli jest wywoływane po t.Parallel(), i co to ujawnia o modelu izolacji testów równoległych w Go?
t.Setenv panikuje, gdy jest wywoływane po t.Parallel(), ponieważ zmienne środowiskowe są stanem globalnym dla procesu. Testy równoległe działają równolegle w tym samym procesie; jeśli jeden test zmodyfikuje PATH, podczas gdy inny go odczytuje, wynik będzie wyścigiem danych i nieokreślonym zachowaniem. Aby temu zapobiec, pakiet testowy Go oznacza środowisko jako "zamrożone" po przejściu testu w tryb równoległy, a każda próba modyfikacji go za pomocą t.Setenv lub os.Setenv wyzwala panikę. To ujawnia, że testy równoległe są zaprojektowane do współbieżności w ramach jednego adresu pamięci, ale zakładają niezmienność stanu współdzielonego lub wyraźną synchronizację. Kandydaci często przeoczeni, że t.Parallel() implikuje surową umowę o "braku mutacji globalnego stanu procesów", co wymaga użycia t.Cleanup, aby przywrócić stan tylko wtedy, gdy test nie był równoległy, lub zaprojektowania testów w celu całkowitego unikania globalnego stanu.