TDD en Go : écrire du code sans peur et sans reproche

Introduction : pourquoi le TDD n'est pas une religion, mais une bouée de sauvetage

Imaginez que vous réparez le câblage dans une vieille maison. Vous coupez le disjoncteur, mais vous avez toujours peur de mettre les mains dans le tableau. C'est à peu près ce que ressent un développeur qui apporte des modifications à un projet sans tests. Surtout en Go — un langage où le typage statique donne un faux sentiment de sécurité.

Le développement piloté par les tests (TDD) en Go n'est ni une tendance à la mode ni un rituel sectaire. C'est une méthodologie qui transforme la peur du refactoring en confiance. Selon une étude d'IBM, les projets utilisant le TDD présentent 40 % de défauts en moins. Et en Go, où le compilateur élimine déjà la moitié des erreurs, le TDD achève les 50 % restants.

Dans cet article, nous ne ferons pas de cours magistraux. Nous allons prendre un problème réel : écrire un petit service HTTP pour raccourcir des liens. Et nous suivrons tout le chemin du TDD — du test rouge au vert et au refactoring. C'est parti !

Qu'est-ce que le TDD réellement ?

Si vous avez entendu parler du Red-Green-Refactor — vous êtes déjà dans le sujet. Sinon, retenez trois étapes simples :

\n
1. Red — nous écrivons un test qui échoue volontairement (parce que la fonctionnalité n'existe pas encore).
\n
2. Green — nous écrivons le code minimal pour que le test réussisse. Pas idéal, juste fonctionnel.
\n
3. Refactor — nous améliorons le code sans changer son comportement. Les tests sont notre filet de sécurité.
\n

En Go, ce cycle est particulièrement agréable grâce au package intégré testing. Vous n'avez pas besoin d'installer jest ou pytest — tout est déjà dans la bibliothèque standard. Mais beaucoup de débutants ignorent les tests, pensant que Go est déjà « sûr ». Et ils ont tort.

Pourquoi le TDD en Go fonctionne-t-il mieux que dans d'autres langages ?

La communauté Go adore la simplicité. Ici, le TDD ne se transforme pas en bureaucratie avec des mocks et des stubs. Au lieu de cela, vous écrivez des tests table-driven (tests pilotés par tableaux) — compacts, lisibles, compréhensibles. Un cas de test — une ligne. Et oui, les tests Go sont rapides. Des millisecondes pour des centaines de cas, c'est normal.

D'ailleurs, le blog officiel de Go a souligné à plusieurs reprises : « Les tests sont la documentation ». Si votre test se lit comme une spécification — vous faites tout correctement.

Configuration de l'environnement : ce dont vous avez besoin pour commencer

Je suppose que Go est déjà installé. Sinon — brew install go ou apt install golang-go. Vérifiez la version : go version. Pour cet article, Go 1.21+ suffit.

Créons le projet :

mkdir url-shortener-tdd\ncd url-shortener-tdd\ngo mod init url-shortener

Prêt. Aucun framework — seulement la bibliothèque standard et le développement piloté par les tests en Go.

Écrire le premier test : Red

Supposons que nous voulions une fonction Shorten(url string) string, qui transforme une longue URL en un hash court. Elle n'existe pas encore — et c'est parfait. Écrivons le test :

// shortener_test.go\npackage main\n\nimport "testing"\n\nfunc TestShorten(t *testing.T) {\n    url := "https://pythonlib.ru/very/long/path?with=params&and=stuff"\n    result := Shorten(url)\n\n    if len(result) == 0 {\n        t.Error("Shorten a retourné une chaîne vide")\n    }\n\n    if len(result) > 10 {\n        t.Errorf("Attendu un hash court, reçu %d caractères", len(result))\n    }\n}

Exécutons : go test -v. Nous voyons du rouge (techniquement — une erreur de compilation). La fonction Shorten n'existe pas. Parfait, nous sommes à l'étape Red.

Code minimal : Green

Maintenant, écrivons juste assez pour que le test réussisse. Pas de cryptographie, juste un hash :

// shortener.go\npackage main\n\nimport (\n    "crypto/sha256"\n    "fmt"\n)\n\nfunc Shorten(url string) string {\n    hash := sha256.Sum256([]byte(url))\n    return fmt.Sprintf("%x", hash[:4]) // on prend les 4 premiers octets\n}

Exécutons à nouveau le test. Vert ? Parfait. Mais le code est horrible — le hash a des collisions, et nous ne vérifions même pas ce