Histoire
Le framework de test Go a introduit t.Parallel() pour s'attaquer à la durée croissante des pipelines CI dans les grandes bases de code. Avant l'adoption généralisée des processeurs multicœurs, les tests s'exécutaient séquentiellement par défaut. À mesure que les projets évoluaient vers des milliers de tests, l'exécution entièrement séquentielle devenait un goulet d'étranglement, mais un parallélisme illimité risquait d'épuiser les ressources processeur comme les descripteurs de fichiers ou les connexions de base de données. L'objectif de conception était de fournir un modèle de concurrence intégré, opt-in qui respectait une limite globale sans nécessiter que les développeurs orchestrent manuellement des pools de travailleurs ou une synchronisation complexe pour chaque suite de tests.
Problème
Lorsqu'un développeur appelle t.Parallel(), le test doit signaler au runner qu'il peut s'exécuter simultanément avec d'autres tests. Cependant, le framework doit appliquer une limite stricte de concurrence (définie par défaut à GOMAXPROCS mais configurable via le drapeau -parallel) pour éviter la famine des ressources. Le défi s'intensifie avec les sous-tests imbriqués : un test parent peut invoquer t.Run plusieurs fois, et chaque sous-test peut également appeler indépendamment t.Parallel(). La solution doit empêcher le parent de libérer son emplacement d'exécution avant que tous ses descendants ne terminent, tout en s'assurant que les sous-tests parallèles profondément imbriqués acquièrent correctement des emplacements du même pool global sans bloquer le parent ou dépasser la limite.
Solution
Le package testing utilise un sémaphore implémenté comme un canal tampon de structures vides (chan struct{}) dimensionné selon la valeur du drapeau -parallel. Ce canal est partagé entre tous les tests d'un package. Chaque instance de T conserve une référence à ce canal parallel et à un canal signal interne pour coordonner avec son parent.
Lorsque t.Parallel() est invoqué :
signal, débloquant l'appel t.Run du parent afin que le parent puisse continuer ou se terminer pendant que le sous-test s'exécute en parallèle.parallel, acquérant un emplacement d'exécution.parallel une fois que la fonction de test retourne et que tous les hooks t.Cleanup s'exécutent.Pour les hiérarchies, t.Run bloque la goroutine parent en utilisant un sync.WaitGroup jusqu'à ce que le sous-test soit entièrement terminé, même si le sous-test s'exécute en parallèle. Cela garantit que le parent conserve son emplacement (ou attend) jusqu'à ce que l'ensemble de l'arborescence de sous-tests soit terminé, empêchant la limite globale d'être dépassée par une série de tests parallèles profondément imbriqués.
// Modèle conceptuel des internals du package de test type T struct { parallel chan struct{} // Sémaphore partagé signal chan struct{} // Signale au parent que Parallel() a été appelé parent *T wg sync.WaitGroup // Attend les sous-tests } func (t *T) Parallel() { // Libère le parent pour continuer close(t.signal) // Acquiert un emplacement du pool global t.parallel <- struct{}{} // Cleanup libère l'emplacement lorsque le test se termine 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 // Attend que le sous-test commence ou appelle Parallel t.wg.Wait() // Attend la fin return !sub.Failed() }
Contexte
Une équipe de plateforme maintenait un monorepo contenant 2 000 tests d'intégration pour une architecture de microservices. Chaque test lançait des conteneurs Docker éphémères pour Postgres et Redis. L'exécution des tests séquentiellement nécessitait 45 minutes, rendant les retours rapides impossibles. Cependant, l'exécution de go test -parallel 100 a fait que les runners CI ont épuisé la limite de max_user_namespaces du noyau, faisant planter l'hôte et corrompre le cache de construction.
Problème
L'équipe avait besoin de limiter les tests intensifs en conteneurs à cinq instances simultanées pour respecter les limites du noyau, tout en permettant aux tests unitaires purs de s'exécuter avec -parallel 32 pour un maximum de débit. Le package de test standard de Go n'accepte qu'une seule valeur globale -parallel par invocation, n'offrant aucun moyen intégré d'appliquer différentes limites à différentes catégories de tests dans le même run.
Solutions considérées
Orchestration externe avec Bazel.
Une migration vers Bazel a été proposée parce que cela prend en charge le sharding de tests et le marquage des ressources (par exemple, tags = ["resources:postgres:1"]). Cela permettrait au planificateur de limiter précisément les tests de base de données concurrents. Cependant, cela nécessitait de réécrire l'ensemble du système de construction et de perdre la simplicité de go test. La courbe d'apprentissage était abrupte, et les flux de travail de développement locaux changeraient radicalement, ralentissant les développeurs peu familiers avec le langage de requête de Bazel.
Sémaphore manuel au sein des suites de tests.
Les développeurs ont envisagé d'ajouter un var dbSem = make(chan struct{}, 5) au niveau du package et de faire en sorte que chaque test d'intégration l'acquière manuellement au début. Cela fournissait un contrôle granulaire mais introduisait un code verbage significatif et risquait un blocage si un test paniquait tout en détenant le sémaphore. Cela fragmentait également le modèle de concurrence : certains tests respectaient le drapeau -parallel, d'autres respectaient le sémaphore personnalisé, rendant le débogage difficile et conduisant à une comptabilité des ressources incohérente.
Séparation par balisage de construction avec des étapes CI.
L'équipe a choisi de séparer les tests en utilisant des balises de construction. Ils ont ajouté //go:build integration à tous les tests conteneurisés et ont laissé les tests unitaires non marqués. Le pipeline CI a d'abord exécuté go test -short -parallel 32 ./... pour les tests unitaires, puis a exécuté séparément go test -tags=integration -parallel 5 ./.... Cela a tiré parti des fonctionnalités existantes de l'outil Go sans modifier la logique des tests. L'inconvénient était de perdre le parallélisme inter-package entre les tests unitaires et d'intégration ; les étapes s'exécutaient séquentiellement. Cependant, puisque les tests unitaires se complétaient en trois minutes, le temps total (3m + 20m) était acceptable et stable.
Solution choisie et résultat
Ils ont choisi la séparation par balisage de construction. Cela nécessitait peu de modifications de code : seules des balises ont été ajoutées aux en-têtes de fichiers et utilisait naturellement le sémaphore du package standard testing sans synchronisation personnalisée. Le CI est devenu stable, les limites du noyau ont été respectées, et les développeurs pouvaient toujours exécuter go test -tags=integration -parallel 4 localement pour le débogage. Le temps total de CI est passé de 45 minutes à 23 minutes, et les plantages de l'hôte ont complètement cessé.
Pourquoi appeler t.Parallel() après avoir lancé une goroutine peut parfois entraîner le journal de cette goroutine dans la mauvaise sortie de test ou paniquer ?
Lorsque t.Parallel() est invoqué, la goroutine de test actuelle se bloque sur le sémaphore, et le runner de test parent continue avec le test suivant. La goroutine lancée, cependant, hérite de l'instance T. Si la fonction de test principale retourne alors que la goroutine est toujours en cours d'exécution, le package de test marque le T comme terminé et ferme ses buffers de sortie. Les appels ultérieurs à t.Log ou t.Error depuis la goroutine orpheline peuvent paniquer avec "Log dans la goroutine après que TestX soit terminé". L'approche correcte consiste à synchroniser l'achèvement de la goroutine en utilisant sync.WaitGroup ou à s'assurer que t.Cleanup attend son achèvement, car t.Parallel() n'attend pas automatiquement les goroutines détachées ; il coordonne uniquement le cycle de vie de la fonction de test avec le runner.
Comment le package de test empêche-t-il un test parent de libérer son emplacement de parallélisme avant que tous ses sous-tests—certains d'entre eux pouvant également appeler t.Parallel()—aient terminé leur exécution ?
La structe T intègre un sync.WaitGroup. Lorsque t.Run est appelé pour créer un sous-test, le parent appelle t.wg.Add(1) avant de lancer la goroutine de sous-test, et le sous-test appelle t.wg.Done() dans une fonction différée à l'achèvement. Crucialement, lorsque un sous-test lui-même appelle t.Parallel(), il décrémente immédiatement le WaitGroup du parent (permettant au parent de terminer potentiellement son propre corps de fonction), mais l'achèvement général du test parent—et donc la libération de son jeton de sémaphore—est bloqué par un dernier t.wg.Wait() dans la chaîne de nettoyage. Cela crée une attente en arbre où le test parallèle racine conserve l'emplacement jusqu'à ce que l'ensemble de l'arborescence des sous-tests sériels et parallèles se termine, garantissant que la limite -parallel reflète avec précision le nombre d'arbres de tests actifs, et non juste les goroutines actives.
Pourquoi t.Setenv pourrait-elle paniquer si elle est appelée après t.Parallel(), et qu'est-ce que cela révèle sur le modèle d'isolation des tests parallèles dans Go ?
t.Setenv panique lorsqu'il est appelé après t.Parallel() car les variables d'environnement sont un état global au processus. Les tests parallèles s'exécutent simultanément dans le même processus ; si un test modifiait PATH tandis qu'un autre le lisait, le résultat serait une condition de course et un comportement non déterministe. Pour prévenir cela, le package de test de Go marque l'environnement comme "gelé" une fois qu'un test devient parallèle, et toute tentative de le muter via t.Setenv ou os.Setenv déclenche une panique. Cela révèle que les tests parallèles sont conçus pour la concurrence au sein d'un seul espace d'adresses, mais supposent un état partagé immuable ou une synchronisation explicite. Les candidats oublient souvent que t.Parallel() implique un contrat strict de "pas de mutation de l'état global du processus", nécessitant l'utilisation de t.Cleanup pour restaurer l'état uniquement si le test n'était pas parallèle, ou la conception de tests pour éviter totalement l'état global.