Discussion :

[thierryler]

Quelques màj sur 3T :

D'abord, je reviens sur l'obligation de créer des interfaces. Je pense que c'est indispensable si on pense travailler avec plusieurs implémentations. Dans le cas contraire, on peut effectivement se contenter d'une classe simple.

Je réaffirme que je suis absolument contre le fait de dire qu'un test qui ne compile pas correspond à l'étape Rouge du TDD. Un test qui ne compile pas, c'est juste du code sans valeur. Ça ne sert à rien !... Je pense que le minimum d'un programme, c'est au moins de compiler (ie. ne pas avoir de croix rouges dans le code). Par contre, ça me va très bien si ça retourne une valeur fausse, une constante ou une UOE.

Et j'insiste une fois de plus sur le fait d'écrire directement tous les tests qui sont connus à l'avance (ie. recopiés des specs) au lieux d'alterner entre tests et code, par itérations.

Et enfin, même si ce n'est qu'une proposition, je suis convaincu que c'est mieux lorsque ce sont des personnes différentes qui écrivent les tests et les codes.

[Logan Mauzaize]

Je suis pas sûr de bien comprendre entre "Un test qui ne compile pas, c'est juste du code sans valeur" et "écrire directement tous les tests qui sont connus à l'avance" ?

[thierryler]

Un test qui compile mais qui reste rouge, c'est ce que je veux. Par contre un test qui ne compile pas, c'est du code pas fini.

Tu me diras, un test rouge, ce n'est pas fini non plus... Tout dépend de la "définition du done"...

Si j'écris le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public Integer foo() {
  return "abcd" / 5;
}

Clairement, ça ne compile pas. C'est juste du n'importe quoi. Parfois ça ne compile pas parce que la méthode "foo" qu'on veut tester n'existe même pas...

Je préfère avoir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public Integer foo() {
  throw new UnsuportedOperationException("...");
}

Ça compile et le message est clair. Du point de vue du test, c'est bon.

[Logan Mauzaize]

Pour résumer (en pseudo-code) ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Loop
   Ecrire les interfaces (éventuellement les factory, etc.)
   Loop
      Ecrire les tests
      Loop
        Passer les tests
        Ecrire le code des implémentations
      End-Loop
   End-Loop
End-Loop

Si c'est le cas, je pense qu'on perd tout de même un élément important fourni par TDD : l'utilisabilité.
Ceci dit c'est surtout vrai pour une bibliothèque et moins pour une application.

Reste tout de même un point : la testabilité ? Je suppose que tu te reposes sur des framework et quelques bonnes pratiques ? Ou alors tu estimes que c'est négligeable ?

[thierryler]

Disons qu'on souhaite développer une fonctionnalité F (éventuellement décomposée en plusieurs sous-fonctions) qui serait spécifiée dans un cahier des charges.

Dans le cas simple, F va donner lieux à la création d'une interface IF avec éventuellement plusieurs implémentations CF1, CF2, etc. ou alors directement à une classe CF.

Ce que dit 3T : on connait dès le départ l'ensemble (ou presque) des fonctionnalités à coder (publiquement) dans CF : M1, M2...

Du coup, je peux écrire des méthodes vides qui compilent (renvoient des UOE) correspondantes à M1, M2, etc. C'est le premier temps de 3T. Et ici, je peux les préparer toutes dès le départ. Ça me garanti de ne pas en oublier. Disons ça garanti de ne pas en oublier une bêtement.

Ensuite, je prépare les tests (JUnit ou autre) relatifs à ces fonctionnalités, avec les variantes identifiées. Je dois coder au minima toutes les variantes indiquées dans les specs. Si je detecte des variantes importantes, je les code aussi et je demande à la MOA de les ajouter dans les spécs...

Ouais ça fait drôle la première fois qu'un développeur demande à son chef de lui donner du taf en plus, surtout s'il précise que ça l'oblige à faire de la qualité et que tout le monde y gagne.

Une fois que ces tests sont écrits, ils sont tous rouges car ils reçoivent des UOE. Mais au moins ça compile.