Le kata Digging Estimator – Part 1 – Le problème

  • Auteur/autrice de la publication :
  • Post category:Tests
  • Commentaires de la publication :0 commentaire

Lors d’un cours que j’ai donné en école sur le sujet des tests, j’ai eu l’occasion de créer le Kata Digging Estimator, basé sur le thème du Donjon de Naheulbeuk (plus précisément, la conférence de PenOfChaos intitulée « DDN – Combien faut-il de nains pour creuser en 2 jours un tunnel de 28 m dans du granite ?« 

Cet article est le début d’une série présentant point par point mon approche de résolution du problème, en Typescript.

Les autres articles :

Vous pouvez trouver le code terminé, avec le détail des commits sur la branche ts-solution du github

Le code

Le code se situe sur mon github : https://github.com/fhemery/digging-estimator-kata

Le problème à résoudre est décrit dans le README.md

A l’heure où j’écris ces lignes, il est disponible dans 5 langages : C#, Java, PHP, Python et Typescript. À quelques subtilités près, l’exercice est le même : reprendre un code difficile à lire (autrement dit, « Legacy »), et ajouter une fonctionnalité dedans.

Ici, il est question de calculer la composition d’une équipe de nains pour creuser un tunnel d’une certaine distance en un certain temps. Les règles régissant la communauté naine sont certes compliquées, mais le code est (volontairement) truffé de mauvaises pratiques. Un exemple :

if (Math.floor(length / days) > maxDigPerRotation) {
  for (let i = 0; i < digPerRotation.length - 1; ++i) {
    if (digPerRotation[i] + maxDigPerRotation < Math.floor(length / days)) {
      composition.nightTeam.miners++;
    }
  }
}

L’approche de résolution

On pourrait sûrement implémenter la fonctionnalité dans le code actuel, qui est quand même moins éreintant que celui du Kata Gilded Rose. Seulement voilà, ce n’est pas le but de l’exercice, sans compter qu’on prend le risque d’introduire une régression… Nous allons donc procéder de la façon standard attendue :

  • Reprendre le contrôle du code, en couvrant le code par des tests (a.k.a. Approval testing)
  • Refactorer le code jusqu’à obtenir quelque chose qu’on comprend
  • Ajouter la nouvelle fonctionnalité dans du code bien propre.

Nous allons nous appliquer à faire des commit le plus fréquemment possible, afin de pouvoir revenir à tout moment à un état stable sans provoquer une escalade d’engagement.

En avant !

C’est parti pour l’étape 1 : Approval testing

Étiquettes: , ,

Laisser un commentaire