Parallel Table-Driven Tests in Go
Voer Go-tests sneller uit met parallelle uitvoering
Table-driven tests zijn de idiomatische manier in Go om meerdere scenario’s efficiënt te testen.
Wanneer gecombineerd met parallelle uitvoering met behulp van t.Parallel(), kunt u de testuitvoeringstijd van de testsuite aanzienlijk verminderen, vooral voor I/O-bound operaties.
Echter, parallelle testen brengen unieke uitdagingen met zich mee rondom race conditions en testisolatie die zorgvuldige aandacht vereisen.
Begrijpen van parallelle testuitvoering
De testing package van Go biedt ingebouwde ondersteuning voor parallelle testuitvoering via de methode t.Parallel(). Wanneer een test t.Parallel() aanroept, geeft het aan de testrunner dat deze test veilig kan worden uitgevoerd met andere parallelle tests. Dit is vooral krachtig wanneer gecombineerd met table-driven tests, waarbij u veel onafhankelijke testgevallen hebt die tegelijkertijd kunnen worden uitgevoerd.
De standaard paralleliteit wordt beheerd door GOMAXPROCS, wat meestal gelijk is aan het aantal CPU-kernen op uw machine. U kunt dit aanpassen met de -parallel vlag: go test -parallel 4 beperkt de gelijktijdige tests tot 4, ongeacht het aantal CPU-kernen. Dit is handig voor het beheren van bronverbruik of wanneer tests specifieke concurrentievereisten hebben.
Voor ontwikkelaars die nieuw zijn in Go-testen, is het begrijpen van de fundamentele principes essentieel. Onze gids over Go unit testing best practices behandelt table-driven tests, subtests en de basisprincipes van de testing package die de basis vormen voor parallelle uitvoering.
Basispatroon voor parallelle table-driven tests
Hier is het correcte patroon voor parallelle table-driven tests:
func TestCalculate(t *testing.T) {
tests := []struct {
name string
a, b int
op string
expected int
wantErr bool
}{
{"addition", 2, 3, "+", 5, false},
{"subtraction", 5, 3, "-", 2, false},
{"multiplication", 4, 3, "*", 12, false},
{"division", 10, 2, "/", 5, false},
{"division by zero", 10, 0, "/", 0, true},
}
for _, tt := range tests {
tt := tt // Capture loop variable
t.Run(tt.name, func(t *testing.T) {
t.Parallel() // Enable parallel execution
result, err := Calculate(tt.a, tt.b, tt.op)
if (err != nil) != tt.wantErr {
t.Errorf("Calculate() error = %v, wantErr %v", err, tt.wantErr)
return
}
if result != tt.expected {
t.Errorf("Calculate(%d, %d, %q) = %d; want %d",
tt.a, tt.b, tt.op, result, tt.expected)
}
})
}
}
De kritieke regel is tt := tt voor t.Run(). Dit vangt de huidige waarde van de lusvariabele, zodat elke parallelle subtest op zijn eigen kopie van de testgevallen werkt.
Het probleem met het vangen van de lusvariabele
Dit is één van de meest voorkomende valkuilen bij het gebruik van t.Parallel() met table-driven tests. In Go is de lusvariabele tt gedeeld over alle iteraties. Wanneer subtests parallel worden uitgevoerd, kunnen ze allemaal dezelfde tt variabele verwijzen, die overschreven wordt terwijl de lus doorgaat. Dit leidt tot race conditions en onvoorspelbare testfouten.
Onjuist (race condition):
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
// Alle subtests kunnen dezelfde tt waarde zien!
result := Calculate(tt.a, tt.b, tt.op)
})
}
Juist (gevangen variabele):
for _, tt := range tests {
tt := tt // Capture the loop variable
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
// Elke subtest heeft zijn eigen kopie van tt
result := Calculate(tt.a, tt.b, tt.op)
})
}
De toewijzing tt := tt maakt een nieuwe variabele die beperkt is tot de iteratie van de lus, zodat elke goroutine zijn eigen kopie van de testgevallen heeft.
Zorg voor testonafhankelijkheid
Voor parallelle tests om correct te werken, moet elke test volledig onafhankelijk zijn. Ze moeten niet:
- Globale staat of variabelen delen
- Gedeelde resources wijzigen zonder synchronisatie
- Aanhankelijk zijn van uitvoeringsvolgorde
- De zelfde bestanden, databases of netwerkresources gebruiken zonder coördinatie
Voorbeeld van onafhankelijke parallelle tests:
func TestValidateEmail(t *testing.T) {
tests := []struct {
name string
email string
wantErr bool
}{
{"valid email", "user@example.com", false},
{"invalid format", "not-an-email", true},
{"missing domain", "user@", true},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
err := ValidateEmail(tt.email)
if (err != nil) != tt.wantErr {
t.Errorf("ValidateEmail(%q) error = %v, wantErr %v",
tt.email, err, tt.wantErr)
}
})
}
}
Elke testgeval werkt met zijn eigen invoerdata zonder gedeelde staat, wat veilig is voor parallelle uitvoering.
Detectie van race conditions
Go biedt een krachtige race detector om data races in parallelle tests op te sporen. Voer altijd uw parallelle tests uit met de -race vlag tijdens de ontwikkeling:
go test -race ./...
De race detector rapporteert elke gelijktijdige toegang tot gedeelde geheugen zonder correcte synchronisatie. Dit is essentieel om subtile fouten op te sporen die mogelijk alleen onder specifieke tijdstippen verschijnen.
Voorbeeld van een race condition:
var counter int // Gedeelde staat - GEDANGEROOS!
func TestIncrement(t *testing.T) {
tests := []struct {
name string
want int
}{
{"test1", 1},
{"test2", 2},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
counter++ // RACE CONDITION!
if counter != tt.want {
t.Errorf("counter = %d, want %d", counter, tt.want)
}
})
}
}
Wanneer u dit uitvoert met -race wordt de gelijktijdige wijziging van counter gedetecteerd. De oplossing is om elke test onafhankelijk te maken door lokaal variabelen te gebruiken in plaats van gedeelde staat.
Prestatievoordelen
Parallelle uitvoering kan de testuitvoeringstijd aanzienlijk verminderen. De snelheidstoename hangt af van:
- Aantal CPU-kernen: Meer kernen laten meer tests tegelijkertijd lopen
- Testkenmerken: I/O-bound tests profiteren meer dan CPU-bound tests
- Aantal tests: Grotere testuitvoeringen zien grotere tijdswinsten
Prestatie meten:
# Sequentiële uitvoering
go test -parallel 1 ./...
# Parallelle uitvoering (standaard)
go test ./...
# Aangepaste paralleliteit
go test -parallel 8 ./...
Voor testuitvoeringen met veel I/O-operaties (databasequeries, HTTP-aanvragen, bestandsbewerkingen), kunt u vaak een snelheidstoename van 2-4x bereiken op moderne meerkernsystemen. CPU-bound tests zien minder voordelen vanwege concurrentie om CPU-resources.
Beheer van paralleliteit
U heeft verschillende opties voor het beheren van parallelle testuitvoering:
1. Beperk het maximum aantal parallelle tests:
go test -parallel 4 ./...
2. Stel GOMAXPROCS in:
GOMAXPROCS=2 go test ./...
3. Selectieve parallelle uitvoering:
Markeer alleen specifieke tests met t.Parallel(). Tests zonder deze aanroep lopen sequentieel, wat handig is wanneer bepaalde tests in een bepaalde volgorde moeten lopen of gedeelde resources gebruiken.
4. Voorwaardelijke parallelle uitvoering:
func TestExpensive(t *testing.T) {
if testing.Short() {
t.Skip("skippend duurzame test in short mode")
}
t.Parallel()
// Duurzame testlogica
}
Algemene patronen en best practices
Patroon 1: Instellingen voorafgaand aan parallelle uitvoering
Als u instellingen nodig heeft die gedeeld worden over alle testgevallen, voert u die uit voor de lus:
func TestWithSetup(t *testing.T) {
// Instellingencode wordt één keer uitgevoerd, voor parallelle uitvoering
db := setupTestDatabase(t)
defer db.Close()
tests := []struct {
name string
id int
}{
{"user1", 1},
{"user2", 2},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
// Elke test gebruikt db onafhankelijk
user := db.GetUser(tt.id)
// Testlogica...
})
}
}
Patroon 2: Per-test instellingen
Voor tests die afzonderlijke instellingen nodig hebben, voert u die uit binnen elke subtest:
func TestWithPerTestSetup(t *testing.T) {
tests := []struct {
name string
data string
}{
{"test1", "data1"},
{"test2", "data2"},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
// Elke test krijgt zijn eigen instellingen
tempFile := createTempFile(t, tt.data)
defer os.Remove(tempFile)
// Testlogica...
})
}
}
Patroon 3: Gemengde sequentiële en parallelle uitvoering
U kunt sequentiële en parallelle tests combineren in hetzelfde bestand:
func TestSequential(t *testing.T) {
// Geen t.Parallel() - loopt sequentieel
// Goed voor tests die in volgorde moeten lopen
}
func TestParallel(t *testing.T) {
tests := []struct{ name string }{{"test1"}, {"test2"}}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel() // Deze lopen parallel
})
}
}
Wanneer u parallelle uitvoering NIET moet gebruiken
Parallelle uitvoering is niet altijd geschikt. Vermijd het wanneer:
- Tests delen staat: Globale variabelen, singletons of gedeelde resources
- Tests wijzigen gedeelde bestanden: Tijdelijke bestanden, testdatabases of configuratiebestanden
- Tests afhankelijk zijn van uitvoeringsvolgorde: Sommige tests moeten voor anderen lopen
- Tests al snel zijn: De overhead van parallelle uitvoering kan de voordelen overschrijden
- Resourcebeperkingen: Tests gebruiken te veel geheugen of CPU wanneer parallel uitgevoerd
Voor databasetests, overweeg het gebruik van transactierollbacks of aparte testdatabases per test. Onze gids over multi-tenant database patronen in Go behandelt isolatiestrategieën die goed werken met parallelle testen.
Geavanceerd: Testen van concurrente code
Wanneer u concurrente code zelf test (niet alleen tests parallel uitvoert), heeft u extra technieken nodig:
func TestConcurrentOperation(t *testing.T) {
tests := []struct {
name string
goroutines int
}{
{"2 goroutines", 2},
{"10 goroutines", 10},
{"100 goroutines", 100},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
var wg sync.WaitGroup
results := make(chan int, tt.goroutines)
for i := 0; i < tt.goroutines; i++ {
wg.Add(1)
go func() {
defer wg.Done()
results <- performOperation()
}()
}
wg.Wait()
close(results)
// Resultaten controleren
count := 0
for range results {
count++
}
if count != tt.goroutines {
t.Errorf("verwacht %d resultaten, gekregen %d", tt.goroutines, count)
}
})
}
}
Voer altijd dergelijke tests uit met -race om data races in de geteste code op te sporen.
Integratie met CI/CD
Parallelle tests integreren naadloos met CI/CD-pijplijnen. De meeste CI-systemen bieden meerdere CPU-kernen, waardoor parallelle uitvoering zeer voordelig is:
# Voorbeeld GitHub Actions
- name: Tests uitvoeren
run: |
go test -race -coverprofile=coverage.out -parallel 4 ./...
go tool cover -html=coverage.out -o coverage.html
De -race vlag is vooral belangrijk in CI om concurrentieproblemen op te sporen die mogelijk niet verschijnen in lokale ontwikkeling.
Debuggen van parallelle testfouten
Wanneer parallelle tests onregelmatig falen, kan het debuggen lastig zijn:
- Voer uit met
-race: Identificeer data races - Beperk parallelle uitvoering:
go test -parallel 1om te zien of fouten verdwijnen - Voer specifieke tests uit:
go test -run TestNaamom het probleem te isoleren - Voeg logboekregistratie toe: Gebruik
t.Log()om de uitvoeringsvolgorde te traceren - Controleer op gedeelde staat: Zoek naar globale variabelen, singletons of gedeelde resources
Als tests sequentieel werken maar falen in parallel, heeft u waarschijnlijk een race condition of gedeelde staatprobleem.
Praktijkvoorbeeld: Testen van HTTP-handlers
Hier is een praktijkvoorbeeld van het testen van HTTP-handlers in parallel:
func TestHTTPHandlers(t *testing.T) {
router := setupRouter()
tests := []struct {
name string
method string
path string
statusCode int
}{
{"GET users", "GET", "/users", 200},
{"GET user by ID", "GET", "/users/1", 200},
{"POST user", "POST", "/users", 201},
{"DELETE user", "DELETE", "/users/1", 204},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
req := httptest.NewRequest(tt.method, tt.path, nil)
w := httptest.NewRecorder()
router.ServeHTTP(w, req)
if w.Code != tt.statusCode {
t.Errorf("verwacht status %d, gekregen %d", tt.statusCode, w.Code)
}
})
}
}
Elke test gebruikt httptest.NewRecorder(), wat een geïsoleerde responsregistratie maakt, waardoor deze tests veilig zijn voor parallelle uitvoering.
Conclusie
Parallelle uitvoering van table-driven tests is een krachtige techniek om de testuitvoeringstijd te verminderen in Go. Het sleutel tot succes is het begrijpen van de vereiste variabelevangst, het zorgen voor testonafhankelijkheid en het gebruik van de race detector om concurrentieproblemen vroegtijdig op te sporen.
Onthoud:
- Vang altijd lusvariabelen:
tt := ttvoort.Parallel() - Zorg dat tests onafhankelijk zijn met geen gedeelde staat
- Voer tests uit met
-racetijdens de ontwikkeling - Beheer parallelle uitvoering met de
-parallelvlag wanneer nodig - Vermijd parallelle uitvoering voor tests die gedeelde resources gebruiken
Door deze praktijken te volgen, kunt u veilig gebruik maken van parallelle uitvoering om uw testuitvoeringen te versnellen, terwijl u betrouwbaarheid behoudt. Voor meer Go-testpatronen, zie onze uitgebreide Go unit testing gids, die table-driven tests, mocks en andere essentiële testtechnieken behandelt.
Bij het bouwen van grotere Go-toepassingen, gelden deze testpraktijken over verschillende domeinen. Bijvoorbeeld, wanneer CLI-toepassingen bouwen met Cobra & Viper, zult u vergelijkbare parallelle testpatronen gebruiken voor het testen van commandohandlers en configuratieverwerking.
Nuttige links
- Go Cheatsheet
- Go Unit Testing: Structuur & Best Practices
- CLI-toepassingen bouwen in Go met Cobra & Viper
- Multi-tenant database patronen met voorbeelden in Go
- Go ORMs voor PostgreSQL: GORM vs Ent vs Bun vs sqlc
