Le CM1 a montré la courbe du coût d'un bug : plus on le découvre tard, plus il coûte cher.

Le TDD attaque cette courbe au moment le moins cher : vous écrivez d'abord la condition qui devra être vraie, puis le code qui la rend vraie.

Autrement dit : au lieu de passer du temps à débugger après, vous investissez quelques secondes à sécuriser avant.

Arrange
Préparer l'environnement, les données, les dépendances.

Act
Déclencher le comportement testé (UNE seule action).

Assert
Vérifier le résultat (idéalement UNE assertion principale).

@Test
void additionne_deux_entiers_positifs() {
  // Arrange
  Calculatrice c = new Calculatrice();

  // Act
  int resultat = c.additionner(2, 3);

  // Assert
  assertThat(resultat).isEqualTo(5);
}

Pas clair

@Test void test1() { ... }
@Test void testAdd() { ... }
@Test void testCalc() { ... }
@Test void bugFix12345() { ... }

On ne sait pas ce qui est testé, ni quel comportement est attendu.

Clair

@Test void additionne_deux_positifs()
@Test void additionne_avec_zero_retourne_lautre_nombre()
@Test void solde_negatif_leve_exception()
@Test void panier_vide_a_un_total_zero()

On lit le test comme une spécification.

@Test
void debut_de_partie_est_0_0() {
  assertThat(new Tennis().score())
    .isEqualTo("0-0");
}
// Impl: return "0-0";

@Test
void apres_point_serveur_15_0() {
  Tennis t = new Tennis();
  t.pointPourServeur();
  assertThat(t.score())
    .isEqualTo("15-0");
}

@Test
void apres_deux_points_serveur_30_0() {
  Tennis t = new Tennis();
  t.pointPourServeur();
  t.pointPourServeur();
  assertThat(t.score())
    .isEqualTo("30-0");
}

@Test
void grille_demineur_5x5() {
  List<String> entree = List.of(
    " *   ",
    "     ",
    "  *  ",
    "     ",
    "   * "
  );
  List<String> sortie =
    new GrilleDemineur(entree).annotee();
  Approvals.verifyAll("", sortie);
}

• Cadrer une intention avant de coder
• Donner un filet pour refactorer sereinement
• Produire une documentation vivante du comportement
• Forcer un découplage (sinon le test devient injouable)

• Garantir que le produit est utile pour le client
• Remplacer la revue de code et le pair programming
• Couvrir les bugs d'intégration, de perf, d'ergonomie
• Dispenser de penser - un test tautologique passera toujours

Dans les arts martiaux, un kata est une séquence de mouvements qu'on répète jusqu'à ce que le corps l'exécute sans y penser.

En programmation, un coding kata est un petit exercice qu'on refait plusieurs fois pour :

• automatiser des gestes (raccourcis IDE, TDD, refactoring)
• essayer des approches différentes
• comparer avec d'autres développeurs

Concept popularisé par Dave Thomas (The Pragmatic Programmer, 2003).

Deux personnes, un clavier.

Terme inventé par Kent Beck et popularisé par Martin Fowler (Refactoring, 1999).

Un code smell est un indice que quelque chose ne va pas dans votre code. Pas un bug, pas une erreur de compilation - juste un signal qui dit :

"Attention, cette zone devient difficile à maintenir."

Un peu comme un aliment qui sent bizarre : pas forcément périmé, mais il faut regarder de près.

Avant (smell : Long Method)

void imprimerFacture(Client c, List<Article> a) {
  // entête
  System.out.println("=== FACTURE ===");
  System.out.println("Client : " + c.nom());
  System.out.println("Date : " + LocalDate.now());

  // lignes
  for (Article art : a) {
    System.out.printf("  %s x%d : %.2f€%n",
      art.nom(), art.qte(), art.prix() * art.qte());
  }

  // total
  double t = 0;
  for (Article art : a) t += art.prix() * art.qte();
  System.out.printf("TOTAL : %.2f€%n", t * 1.20);
}

Après

void imprimerFacture(Client c, List<Article> a) {
  imprimerEntete(c);
  imprimerLignes(a);
  imprimerTotal(a);
}

void imprimerEntete(Client c) {
  System.out.println("=== FACTURE ===");
  System.out.println("Client : " + c.nom());
  System.out.println("Date : " + LocalDate.now());
}

void imprimerLignes(List<Article> a) { /* ... */ }

double calculerTotalHT(List<Article> a) {
  return a.stream()
    .mapToDouble(x -> x.prix() * x.qte()).sum();
}

Avant (smell : Switch Statements)

class Animal {
  String type;

  String faireDuBruit() {
    switch (type) {
      case "chien":  return "Wouf !";
      case "chat":   return "Miaou !";
      case "vache":  return "Meuh !";
      case "canard": return "Coin coin !";
      default: throw new IllegalStateException();
    }
  }
}

Chaque nouveau type → modifier cette classe.

Un switch sur le type est souvent dupliqué.

Après

abstract class Animal {
  abstract String faireDuBruit();
}

class Chien extends Animal {
  String faireDuBruit() { return "Wouf !"; }
}

class Chat extends Animal {
  String faireDuBruit() { return "Miaou !"; }
}

class Vache extends Animal {
  String faireDuBruit() { return "Meuh !"; }
}

Nouveau type → nouvelle classe. Pas touche au reste.

Un refactoring manuel est risqué. Un oubli, un mauvais remplacement → comportement changé.

Les TP se font dans le Codespace VS Code avec l'extension Java officielle (Red Hat). Les gestes de refactoring passent par deux entrées :

• Ctrl+. (ou Cmd+. sur Mac) : menu Quick Fix + Refactor contextuel. Propose Extract to method, Extract to constant, Extract to variable / field, Move..., Inline..., Add unimplemented methods selon ce que le curseur touche.
• F2 : Rename (propage partout, imports + Javadoc inclus).

Concept de Michael Feathers (Working Effectively with Legacy Code, 2004).

Legacy code = du code sans tests, qu'on doit faire évoluer.

Problème : on veut refactorer, mais sans tests on n'a pas de filet.

Solution : des characterization tests - des tests qui décrivent le comportement actuel du code, qu'il soit "juste" ou non.

Créé par Terry Hughes, popularisé par Emily Bache.

Un magasin vend des articles qui évoluent tous les jours :

• Articles normaux (perdent en qualité)
• Aged Brie (gagne en qualité)
• Sulfuras (immuable)
• Backstage passes (complexe)
• Conjured (à ajouter)

Le code source tient en 35 lignes - mais quelles lignes. if imbriqués, noms cryptiques, duplication partout.

Votre mission :

1. Comprendre (characterization tests)
2. Refactorer (sans casser)
3. Ajouter la fonctionnalité Conjured

• vous allez toucher cette zone dans les prochains mois
• le smell ralentit concrètement une feature ou un bug fix
• vous avez des tests qui prouvent que rien ne casse
• c'est l'endroit précis où vous intervenez (règle du scout)

• le code marche, est stable et personne ne le touche
• vous le faites juste parce que "c'est pas joli"
• il n'y a pas de tests pour sécuriser - vous allez casser
• vous refactorez et ajoutez une feature en même temps

int d;

List<Integer> list;

void doStuff() { ... }

boolean flag = true;

int joursRestants;

List<Integer> ageEtudiants;

void envoyerRappel() { ... }

boolean estInscrit = true;

Commente pour compenser

// Vérifie si l'utilisateur a plus de 18 ans
if (u.getA() > 18) { ... }

→ Renomme plutôt : if (utilisateur.estMajeur()).

Commente le pourquoi

// Le SDK distant exige un id positif strict ;
// 0 provoque un NPE côté serveur.
if (id <= 0) throw ...;

→ Information qui ne peut pas être déduite du code.