Pratique du TDD, comment convertir des chiffres en nombres romains ?

Les chiffres romains ne sont plus guère utilisés aujourd’hui. Cette représentation est pourtant encore visible au quotidien sur certaines montres et la plupart des horloges. Cette façon d’écrire des nombres, née avec des symboles tracés avec un bâton dans de la glaise, a évolué pour représenter, à l’époque romaine, des caractères de l’alphabet. Aujourd’hui, la technologie a elle aussi (un peu) évolué. Résultat, pour la plupart d’entre nous, nous ne savons plus écrire rapidement un nombre en chiffres romains… mais nous pouvons l’automatiser ! Si la page Wikipedia qui présente la numération romaine n’est malheureusement pas suffisamment développée, elle permet néanmoins d’en tirer des spécifications. J’en ai donc profité pour le faire en TDD (test driven development) afin d’en exposer les principes, de démontrer son intérêt en vue de faire émerger un algorithme, et d’aider à surmonter quelques difficultés. Voyons donc comment convertir des chiffres en nombres romains en java.

TDD : le cycle Red Green Refactor

Le principe du TDD repose sur le cheminement RED, GREEN, REFACTOR. L’état RED correspond à un test qui ne passe pas, le GREEN représente tous les tests qui passent et le REFACTOR, le moment où, alors que tous les tests passent, on en profite pour refactorer le code, c’est-à-dire le rendre « plus MIEUX. »

De quoi s’agit-il ? Le « plus MIEUX » est quelque peu compliqué à décrire. Il consiste à le rendre plus propre, plus élégant. On peut utiliser quelques métriques comme la complexité cyclomatique, le nombres de lignes, mais ce ne sera pas suffisant. On peut aussi éliminer les “codes smells” que l’on détecte, les “feature envy”, la “duplication”, la “long parameter list”, etc. à l’appréciation du développeur. Il est aussi possible d’optimiser la lisibilité en améliorant le nommage. En réalité, personne n’est vraiment d’accord sur les qualités requises.

Les étapes du TDD

Mais voici un exemple de ce qu’en dit Kent Beck dans son livre Extreme Programming :

  • Valider les tests (Passes the tests)
  • Expliciter l’intention (Reveals intention)
  • Pas de duplication (No duplication)
  • Le moins d’éléments possible (Fewest elements)

Il y décrit une hiérarchie de valeur, depuis la plus importante – à savoir le code passe les tests –, pour ensuite insister sur une notion de lisibilité et, seulement en dernier, une réduction du nombre d’éléments. C’est un point de vue, certes, mais qui offre une feuille de route pour commencer à s’approprier le sujet.

Le déroulement d’une session d’écriture de code peut-être décrite telle que suit par UncleBob (Robert C.Martin) :

TDD:

  • Write no production code without a failing test,
  • Stop writing that test as soon as it fails, or fails to compile,
  • Stop writing production code as soon as the failing test passes,
  • Refactor both and then repeat,
  • Cycle time: ~10-60 seconds,
  • Ne pas écrire de code non motivé par un test qui échoue,
  • Arrêter d’écrire des tests dès qu’un test échoue ou ne compile pas,
  • Arrêter d’écrire du code dès que les tests passent,
  • Refactorer le code et les tests, et recommencer,
  • Le temps d’un cycle doit être inférieur à une minute.

Insistons sur quelques points : on n’écrit qu’un seul test à la fois ; chaque incrément doit être court ; on refactore systématiquement le code ET les tests ; on n’écrit pas de code, si aucun test ne le motive !

Baby Steps

La plus grande difficulté que l’on rencontre en débutant la pratique du TDD est de choisir le nouveau test à écrire. Il faut choisir la fonctionnalité qui va permettre un petit incrément, si possible le plus petit, mais la taille n’est pas le seul paramètre à prendre en compte. Les tests vont être de plus en plus « spécifiques » et le code de plus en plus « générique ». Il est nécessaire de choisir la fonctionnalité qui spécialise le moins les tests existants. Pour résumer, il faut trouver un nouveau cas d’utilisation non encore passant et qui soit le plus proche de l’existant.

Design Code / Algo émergent

Un des avantages de l’approche TDD est de toujours être en mouvement et de découper en petits incréments abordables. L’appréhension de « la page blanche », le fait d’avoir l’ensemble de l’implémentation en tête avant de commencer, est ainsi évité. Toutefois, il est nécessaire de diriger les refactorings et le choix de chaque nouvelle étape pour construire « sa » solution. Régulièrement, il est nécessaire lors de la phase de refactoring de diriger, afin de généraliser l’algorithme, ou d’introduire le design désiré au moment présent.

La phase de refactoring sert à rendre le code propre, mais est également l’emplacement où le développeur (ou la paire de développeurs PairProgramming ++) va introduire le design applicatif et aider l’algorithme si besoin à émerger en généralisant les aspects importants.

Step by Step video

Let’s code -> La vidéo du Kata !!

KATA TDD Roman Converter

N’hésitez pas à effectuer l’exercice avant de visualiser la vidéo ou de lire le reste de l’article 😊

Prérequis, j’ai effectué quelques choix avant le début de l’exercice. J’utilise Junit pour les tests, et AssertJ pour écrire les assertions de manière fluent et élégante (scannability > readability).

Je vais également nommer ma classe de test en la suffixant par « Should » afin d’avoir des tests nommés comme une phrase. Cela nécessite avec Maven de lui indiquer le pattern particulier utilisé :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<includes>
<include>**/*Should</include>
</includes>
</configuration>
</plugin>

Je préfère également utiliser le GWT (Given, When,Then) que le AAA (Arrange, Act, Assert) dans les commentaires à l’intérieur des méthodes de tests. Il favorise en effet plus facilement une écriture en langage naturel, et il incite davantage à penser au « pourquoi » lors de l’écriture du test, à réfléchir en termes de fonctionnalités plutôt qu’en terme de lignes de code (ce n’est pas faire du BDD, le test est ici écrit par le développeur, en code et en même temps que le code de production, et non par un représentant métier dans un langage dédié en tant que spécification exécutable.). Ces commentaires sont systématiques, pour en faire une habitude, à la fois pour moi mais aussi pour ceux qui liront le code.

Comment concrètement appliquer la méthode TDD

Mains sur le clavier et c’est parti ! On commence par écrire une classe de tests. Ici, on choisit déjà un certain nombre de points : un nom de package, de classe, la façon d’appeler, les types que l’on souhaite, etc. Le premier test ne compilera pas !

Retourner une constante

La première implémentation, la plus simple qui permet de valider le test, est de retourner simplement une constante. L’intérêt fonctionnel d’un tel code est léger, mais déjà le code peut être embarqué dans un système et permettre des premières « techniques » d’intégration.

À chaque étape, on cherche à conserver le code le plus simple, en autorisant la transformation la moins « chère » possible. Ce concept de coût de transformation a été décrit en liste par Robert C.Martin. En voici une interprétation simplifiée :

  • Pas de code -> constante
  • Constante simple -> variable
  • Statement -> bloc de statements
  • Pas de condition -> if
  • Variable -> tableau
  • Tableau -> structure
  • Statement -> recursion
  • if -> while
  • Expression -> fonction
  • Variable -> assignation

Cette ébauche d’échelle de coût est une aide pour décider de ce que doit être l’implémentation la plus simple qui correspond à la validation d’un nouveau test. Les tests I, II, III sont d’abord implémentés par des « if ». Ensuite, un refactoring va introduire une boucle « for ».

devient

Un embranchement des possibles

L’étape suivante correspond à un embranchement des possibles. Résumons. On peut choisir le IV, mais on doit l’écarter car il introduit un test beaucoup trop spécifique par rapport à l’avancée du code actuel. En effet, il introduit :

  • Un nouveau symbole : le X
  • Une nouvelle représentation : la demi-unité
  • Et un nouveau concept : la notation soustraction

On écarte, pour des raisons similaires, le V qui introduit un nouveau symbole et la représentation en demi-unité. Je choisis le X.

La répétition des symboles

À l’étape suivante, on est face à deux options : le XX ou le XI. Je cherche à orienter sur la répétition des symboles. D’abord, je choisis donc d’écrire le test du XX.

La notion de reste

L’étape délicate suivante se passe lors d’un refactoring quand on a validé le XI. Il faut reconnaître la division euclidienne classique et introduire la notion de reste. Cette étape implique la transformation des boucles « for » en « while ».

On transforme donc les for en while :

J’introduis ensuite un « enum » qui fait le lien entre un symbole et sa valeur. On itère sur les éléments de l’énumération :

On utilise l’enum dans la méthode :

On sépare les abstractions en extrayant l’appel à la liste ordonnée des valeurs de l’enum :

L’algorithme n’est alors plus itératif, suite de boucles et de conditions, mais déclaratif, par construction de l’enum.

La construction du résultat

Le refactoring suivant introduit une nouvelle structure qui va encapsuler la construction du résultat et la gestion du reste :

La méthode principale ne comporte plus que l’ordonnancement :

  • Je crée le builder de résultat
  • Pour chaque symbole de notation romaine du plus grand au plus petit, j’applique l’algorithme
  • Je retourne le résultat

Analyse critique

Doit-on s’arrêter là ?

L’algorithme ainsi construit correspond à un dictionnaire de symboles, dans lequel les valeurs IV et V sont présentes. La notion de soustraction n’a pas été abordée, mais évitée par une « constante » dans le dictionnaire. Doit-on continuer les refactorings pour faire émerger ce concept ? Je pense personnellement que cela n’est pas nécessaire. Le code passe les tests, les intentions sont explicites et il y a peu de duplication.

Dois-je refactorer les tests ?

On doit refactorer les tests en même temps que le code. Ici, il n’y a pas d’étape où je refactore les tests, les structures sous-jacentes n’évoluant pas.

Tests paramétrés ou tests autonomes

Je préfère des tests autonomes quand les fonctionnalités sont autonomes. C’est-à-dire : je sépare les fonctionnalités par des cas, donc je sépare les tests. Je pourrais en revanche utiliser un test paramétré quand le cas d’utilisation est décrit d’une manière différente (ex : write_a_I_for_each_unit).

Duplication ou initialisation dans un @before ?

Je privilégie la duplication du corps de la méthode de test en général : je préfère en effet que la lecture du test soit suffisante à la compréhension de ce qu’il fait et qu’il puisse indiquer clairement son intention.

Suivi de la technique, step par step sans porter beaucoup d’attention au domaine

Cette critique est moins agréable mais très pertinente. L’exercice tel que décrit dans la vidéo est très technique. Il présente les concepts du TDD et un exemple de suivi de la méthode mais il ignore complétement le domaine.

Eclipse

Oui.

Autre cheminement

En s’intéressant plus au domaine et à ce que représente une notation de nombres, la description des tests sera différente.

On commencera par expliquer que la notation commence par des traits tracés et que leur nombre donne la valeur. Ensuite, on ajoutera un regroupement de symboles (des remplacements sur la chaîne de caractères construite) ou un regroupement de valeur (division euclidienne). Le cheminement peut donc être le même ou très différent. Et si vous m’expliquiez votre manière de faire à vous ?

Conclusion

Un kata est un exercice que l’on répète pour acquérir des réflexes. Dans cet exercice, on insiste principalement sur le choix du test suivant et sur un refactoring systématique pour faire émerger la solution. D’autres cheminements sont possibles et peuvent aboutir à des codes très différents ou parfois très proches. Le principal est de recommencer. C’est le principe même du Kata.

Retrouver le code produit ici

Laisser un commentaire

MERITIS ICI. ET LÀ.

Carte Meritis

Meritis Paris

5 – 7, rue d’Athènes
75009 Paris

+33 (0) 1 86 95 55 00

contact@meritis.fr

Meritis Sophia Antipolis

Les Algorithmes – Aristote B
2000 Route des Lucioles
06901 Sophia Antipolis Cedex

+33 (0) 4 22 46 31 00

contact@meritis-paca.fr

Meritis Aix-en-Provence

240 Rue Paul Langevin
13290 Aix-en-Provence

+33 (0) 4 22 46 31 00

contact@meritis-paca.fr

Meritis Nantes

Immeuble Skyline
22 mail Pablo Picasso
44000 Nantes

contact@meritis-technologies.fr

+33 (0)2 85 67 07 00

Meritis Montpellier

1095 Rue Henri Becquerel
34000 Montpellier

+33 (0) 1 86 95 55 22

contact@meritis.fr


Contactez-nous

Pour connaître et exercer vos droits, concernant l'utilisation des données collectées par ce formulaire, veuillez consulter la page sur notre politique de confidentialité.