Tdd on Simple Enough Blog

Test-Driven Infrastructure : appliquer le TDD à l’Infrastructure as Code

Wed, 14 Jan 2026 13:45:30 +0200

Test-Driven Infrastructure

Appliquer le TDD à l’Infrastructure as Code

Le Test-Driven Development (TDD) est aujourd’hui bien installé côté applicatif.
En revanche, lorsqu’il s’agit d’infrastructure, beaucoup considèrent encore que le TDD est inutile, trop complexe ou inadapté.

C’est une erreur.

Le TDD appliqué à l’infrastructure existe déjà, souvent sans être nommé. Lorsqu’il est bien compris, il devient un levier majeur pour sécuriser, structurer et faire évoluer une plateforme cloud.

Utiliser les constantes en TDD avec Go

Tue, 23 Dec 2025 10:08:49 +0200

Bonnes pratiques, pièges et signaux de design

Le Test-Driven Development (TDD) ne sert pas uniquement à écrire des tests.
Il sert avant tout à concevoir du logiciel.

En Go, l’usage des constantes est souvent mal compris en TDD :

faut-il les exposer ?
les tester ?
les injecter ?
les éviter ?

Cet article propose une approche pragmatique et idiomatique Go, issue de l’expérience terrain, pour comprendre quand une constante est un bon design… et quand elle cache un problème.

Interfaces, Fonctions et Modules en Go : Structurer son code pour le TDD sans le complexifier

Mon, 15 Dec 2025 10:08:49 +0200

I. Introduction

Go est un langage minimaliste, mais cette simplicité peut donner l’impression qu’il “manque quelque chose” lorsqu’on aborde des architectures plus poussées, du Test-Driven Development ou la nécessité de mocker certaines dépendances. Très vite, les développeurs venant de Java, C# ou Python se posent les mêmes questions :

Dois-je transformer toutes mes fonctions en structs + interfaces pour tester ?
Comment organiser mes packages pour qu’ils soient modulaires et testables ?
Où placer les interfaces ? Chez le fournisseur ou chez le consommateur ?
Comment isoler un package qui expose uniquement des fonctions ?
Comment détecter automatiquement un changement de signature ?

II. Le modèle Go : simple, modulaire, mais différent

Contrairement à Java ou C#, Go ne repose pas sur l’héritage, les classes ou les gros frameworks d’injection de dépendances.