qualité-code

Onzième article de la série Testing Go. Ce que go test -race mesure vraiment (data races, pas race conditions), son moteur ThreadSanitizer emprunté à LLVM, comment écrire un test qui déclenche volontairement une race, les patterns les plus fréquents selon l'étude Uber PLDI 2022 sur 46 M de lignes Go, le combo t.Parallel() + -race, les trois outils de synchronisation (mutex/WaitGroup/channels) dans les tests, et les limites du détecteur (faux négatifs).

Dixième article de la série Testing Go. Ce que go test -cover mesure vraiment (basic blocks, pas branches), les modes set/count/atomic, pourquoi une ligne couverte n'est pas une ligne testée, la loi de Goodhart appliquée aux seuils CI, le paper Inozemtseva & Holmes 2014 qui démonte la corrélation coverage ↔ qualité de tests, diff-cover pour ne mesurer que la coverage diff des PR, et le mutation testing comme seule métrique qui attrape vraiment les tests vides.

Neuvième article de la série Testing Go. Limites des mocks, taxonomie unit/intégration/end-to-end, Testcontainers-Go pour lancer de vraies dépendances dans go test, module postgres.Run et module redis.Run, le cycle de vie complet (pull d'image, wait strategy, Ryuk qui tue les orphelins), TestMain pour partager un container entre tests, build tag //go:build integration pour isoler les tests qui coûtent cher, et les pièges d'isolation entre tests qui partagent un container.

Huitième article de la série Testing Go. testing.B et b.N, les pièges classiques (ResetTimer oublié, dead-code elimination), la nouvelle API b.Loop() de Go 1.24, table-driven benchmarks, benchstat pour comparer deux runs avec p-value et intervalle de confiance, pprof CPU/mémoire, et l'exercice central : demander à l'IA d'optimiser une fonction, mesurer les deux versions, et découvrir si l'optimisation est réelle, neutre ou une régression déguisée.

Septième article de la série Testing Go. testing.F, f.Add et f.Fuzz expliqués sur un cas concret (un truncate UTF-8 qui crashe), le rôle du seed corpus, la minimisation automatique, le dossier testdata/fuzz pour rejouer les bugs en regression, les types supportés (et la frustration des structs), et pourquoi le fuzzing est le seul filet qui attrape les bugs que l'IA n'imagine pas.

Sixième article de la série Testing Go. La différence cruciale entre assert et require (et pourquoi te tromper coûte cher en debugging), suite.Suite pour les tests stateful, le combo Testify + table-driven tests, et l'opinion qui fâche : quand est-ce que testing.T natif est meilleur que Testify, et pourquoi une partie des projets Go gagneraient à supprimer la dépendance.

Cinquième article de la série Testing Go. Pourquoi Go n'a pas de Mockito, comment écrire un mock manuel en quinze lignes, quand passer à Testify ou uber-go/mock, et surtout pourquoi l'IA crée systématiquement des mocks qui testent l'implémentation interne au lieu du contrat public.

Quatrième article de la série Testing Go. httptest permet de tester un handler HTTP sans lancer de serveur, sans réseau, sans flake. On voit NewRecorder pour l'unitaire, NewServer pour l'intégration, les cinq trous typiques de l'IA, et un pattern setupTestRouter réutilisable.