Pages

Tuesday, February 21, 2012

Le TDD n'est pas naturel mais très addictif!

Danger

Il faut faire très attention! : un peu comme la chirurgie esthétique, le TDD n'est pas une démarche naturelle mais une fois qu'on y a goûté, cette démarche a un fort pouvoir addictif! (désolé, je n'ai pas trouvé mieux comme métaphore :-))

extrait Nip Tuck
Le TDD c'est :

Le TDD signifie Test Driven Developpement ou Développement Dirigé par les Tests. Comme son nom l'indique c'est une méthode de développement basé (et même dirigé par les tests). L'idée principale est, pour développer une fonctionnalité, de faut d'abord l'exprimer sous forme de tests et d'ensuite développer la fonctionnalité pour faire passer le Test.

On entend souvent parler de "red, green, refactor" pour décrire le TDD :
- D'abord écrire un test qui échoue (vous exécutez votre test dans votre IDE et "la barre est rouge")
- Ecrire le code pour que le test passe  (vous exécutez votre test dans votre IDE et "la barre est verte")
- Refactorer le code pour le rendre clair, lisible, limpide pour fair simple : beau!

Me
Pfff... Après y avoir goûté, on se retrouve à porter des tee-shirts ridicules de geek sur le TDD... :-)

Une des pratiques du TDD poussée à l’extrême est le "TDD as you meant it" qui consiste globalement à tout écrire dans la classe de test (même le code pour faire passer le test) et de ne déplacer les méthodes en refactorant qu'une fois que le test passe.

Constat:
Le TDD n'est pas une démarche naturelle. C'est quelque chose qui fait partie de l'évolution du développeur. En revanche quand on y a goûté, c'est une démarche qui parait naturelle et qu'on a envie de reproduire.
Evolution de l'homme
Quand on commence sa vie de développeur, on ne commence pas à directement faire du TDD. Je pense que la démarche est de d'abord comprendre la technologie, le langage et ses concepts avant de faire des Test Unitaires puis du TDD. Vous souvenez vous de la première ligne de code Java que vous avez écrite?

C'était plutôt ça :
public static void main(String[] args) {
        System.out.println("hello world");
    }

ou plutôt ça :
@Test
public void shouldSayHelloWorld() throws Exception {
    HelloWorld hello = new HelloWorld();
    assertThat(hello.say()).isEqualTo("Hello World");
}

Moi, par exemple, j'ai commencé par la première façon pas par la deuxième. J'imagine que pour beaucoup d'autres nous (les développeurs) c'était aussi le cas. CQFD :

Le TDD n'est pas une démarche facile et naturelle!

Le TDD est une démarche vers laquelle un développeur peut, suivant son évolution et son contexte, avoir envie d'adopter. Cette évolution n'est pas forcément liée à un facteur temps: l'adoption peut être rapide ou ne jamais arriver.

La difficulté du TDD est que pour vraiment comprendre la démarche, je pense qu'il faut l'avoir pratiqué ou l'avoir vu pratiquer. Je pense qu'il est donc difficile de convaincre quelqu'un de faire du TDD simplement en échangeant sur le sujet. La meilleure solution dans ce cas, c'est de lui proposer d'essayer!

Envie d'y goûter?
Pour illustrer l'idée, je vais reprendre la désormais célèbre scène de Matrix : la pilule bleu ou la pilule rouge. L'idée c'est donc ça :

extrait Matrix
  • Si tu ne dors plus la nuit car tu n'as pas confiance dans le code de ton application
  • Si tu es fatigué après chaque modification de code de devoir passer en mode debug pour voir comment se comporte ton code
  • Si à chaque message de commit tu as envie d'écrire "banzaï, on verra bien si ça marche"
  • Si tu as peur de refactorer ton code par peur de tout casser
  • Si tu ne sais pas comment concevoir ton application car cela te parait trop compliqué et que tu aimerais commencer simplement...
C'est que tu es forcément attiré une autre réalité... et la pilule rouge du Tests Unitaires et du TDD te fait de l'oeil.

A la différence de Matrix, une fois que vous avez pris la pilule rouge, il vous reste encore tout à faire... Comment concrètement vous y mettre :

Les outils gravitant autour des tests unitaires du TDD (Java oriented):
Il existe une ensemble d'outillage pour vous aider à faire du TDD :
  • une librairie de tests unitaires : JUnit. Le framework de base pour faire des tests unitaires en Java.
  • des facilitateurs technologique : *Unit. Ces librairies ont pour but de venir en complément pour simplifier les tests liés à certaines technologies (DBUnit vous aidera sur des tests avec une BDD relationnelle, JWebUnit vous aidera sur des tests avec une application WEB , HtmlUnit vous aidera à tester du HTML, XmlUnit vous aidera à tester du Xml, CassandraUnit vous aidera sur des tests avec Cassandra...)
  • des facilitateurs sur la lisibilité du test (notamment sur les assertions) : Hamcrest ou Fest-Assert.
  • les librairies de Mock : Les objets "mocké" sont globalement des objets utilisés dans les tests dont on maîtrise le comportement pour tester d'autres objets (JMock ou Mockito par exemple).
  • des librairies s'intégrant dans votre IDE pour faire du test en continu comme InfiniTest.

Le TDD partout?
C'est toujours plus facile à dire qu'à faire. Hum, tout un débat possible en perspective... Je ne suis pas un intégriste sur la question, je dirais simplement qu'il y a parfois beaucoup moins de plus value à faire du TDD sur certains couches applicatives... Par exemple, faire du TDD pour tester que quand on clique sur un bouton et bien ça clique sur le bouton...


Le TDD sur du code existant
Oui et oui. Cet article de Xebia ici l'explique d'ailleurs très bien.

Pour conclure
Je pense qu'il y a un réel fossé entre un développeur qui a déjà fait du TDD et un qui n'en a jamais fait. Chacun trouve d'ailleurs que l'autre est un extra terrestre :-). Je pense qu'une fois de plus, c'est une démarche très intéressante que j'ai adoptée mais je comprend aussi que dans certains contextes il est difficile de la mettre en oeuvre. De toute façon, le TDD, c'est un peu la cerise sur le gâteau, car il est très difficile d'expliquer les avantages du TDD lorsqu'il faut parfois commencer par expliquer l'avantage de faire des tests!

Le plus simple en tous cas avec le TDD pour vous faire votre propre avis, c'est d'y goûter :-)

2 comments:

Damien METZLER said...

En cours un élève me dit : "Mais monsieur, faire du TDD c'est coder à l'envers ?"..... ou pas.... :-)

Annette Caron said...

La procédure typique d'utilisation des marchandises d'acheter des produits keto dépendra d'une thérapie de 30 jours dans laquelle nous acquérons deux comprimés par jour et la buvons dans de l'eau en verre. Ce n'est donc pas seulement une méthode qui devrait être beaucoup plus difficile et, en principe, chaque personne devrait être capable de gérer