Test-Driven Development - Episode1: Introduction

Posté par | septembre 18, 2013 | TDD | 8 Commentaires
rgr

Salut la compagnie! Si vous lisez ce post c’est que vous êtes sûrement un développeur, right? Si c’est le cas, j’ai une p’tite question pour vous. Techniquement, comment faites-vous pour montrer que votre code fonctionne comme prévu? La solution la plus évidente je crois serait de compiler le programme et de voir le résultat. Et hop, it runs!  Super! Cependant ne vous limitez pas seulement à ce que votre code marche, vous devez le prouver, le prouver encore et encore, de la première ligne de code écrite jusqu’à la dernière! Le meilleur moyen de prouver cela sont les tests automatisés. Ce n’est pas ce genre de tests que vous effectuez à la fin du développement, je vous parle ici du Test-Driven Development (ou TDD).

Le Test-Driven Development, kézako?

Avant de répondre à cette question, intéressons-nous d’abord aux tests unitaires. Ces derniers consistent à tester différents blocs de notre application (les méthodes par exemple) pour nous assurer qu’ils retournent bien le résultat attendu.

Exemple de tests unitaires

Etape 1: Ecrire la logique

Etape 2 : Ecrire le(s) test(s)

Là  nous testons et validons les méthodes individuellement. Le TDD est semblable à cela à la différence que nous écrivons le test d’abord avant d’écrire une seule ligne de code de production comme suit:

Etape 1 : Ecrire le(s) test(s)

Etape 2: Ecrire la logique

Houla, une minute please! Je ne peux pas tester une méthode que je n’ai pas encore écrite!

Si, vous pouvez, et c’est exactement ce qui se fait en TDD. Par exemple vous écrivez un test qui essaie d’instancier un objet dont la classe n’est pas encore implémentée, ou un autre qui appelle une méthode qui n’existe pas encore, vous exécutez ces tests et ils échouent car vous n’avez pas encore écrit le code de production qui les fait passer. C’est le principe fondamental du TDD, avant d’écrire la toute première ligne de code, on écrit d’abord un test qui va échouer automatiquement et seulement après cela, on écrit le minimum de code possible pour faire passer le test d’où son appellation Test-Driven Development (Développement Piloté par les Tests).

Ok, tu nous parles de tests depuis tout à l’heure, mais que faut-il réellement tester?

TOUT! Absolument tout ce qui est susceptible de casser le code ou de causer des bugs doit être testé. Cette variable est de type Object ou Array? Ecrivez un test pour le vérifier. Est-ce que cet objet est bien une instance de la classe souhaitée? Testez-le. Peur qu’une de vos routes ne fasse pas une bonne redirection, provoquant une page d’erreur 404? Ecrivez un test qui détecte cette erreur le plus rapidement possible. Et cette classe qui récupère des données d’une table et les met dans un fichier comme rapport, dois-je la tester? Absolument. Qu’en est-il de ce helper qui me récupère mes derniers tweets et les ajoute dans le sidebar de mon blog? Encore une fois, testez-le! Ecrivez des tests jusqu’à ce que vos peurs s’évanouissent.

Avantages et inconvénients des tests

A ce stade, vous pourriez penser que les tests ne servent uniquement qu’à prouver que votre code marche comme prévu, vous avez tout faux, ce n’est pas le seul but. Il y a beaucoup d’avantages qu’on peut tirer du TDD.

1. La Sécurité:

Avez-vous fait accidentellement une erreur ou casser une fonctionnalité? Le “test robot” vous le signalera automatiquement. Imaginez que vous faites une édition, cliquez sur enregistrer et boom, une notification appârait vous disant que quelque chose ne va pas.

2. Contribution:

Supposons que vous êtes un groupe développant une application où chacun aura pour rôle de développer un module. Si votre projet ne contient pas une série de tests, quand un des membres du groupe greffera son module, comment pourriez-vous savoir si ces changements n’ont pas eu d’impacts négatifs sur votre app? La réponse? Vous ne pouvez pas, sans manuellement tester tout le scénario possible de son module. Si vous aviez écrit des tests plutôt, une fois des modifications apportées, vous exécutez ces tests et hop, il vous signalera s’il y a bug quelque part.

3. Documentation:

Ecrire des tests vous garantira de la documentation pour votre système. Envie de savoir quelle fonction remplit cette classe? Exécutez les tests et s’ils sont nommés proprement, vous comprendrez en un rien de temps.

4. C’est Amusant:

Nous sommes des geeks, n’est ce pas. Quel geek n’aime pas jouer? Quand on fait du TDD, nos développements peuvent vite se transformer en un jeu. Comment je vais faire pour faire passer ce code du rouge (test qui échoue) au vert (test qui passe)? Ça peut être déroutant au premier abord, mais je vous promets que c’est très amusant si vous savez écrire des tests ;)

Nous arrivons maintenant aux inconvénients. Pour ma part je n’en trouve aucun! Certains me diront, “Ouais, écrire des tests me prendra beaucoup plus de temps dans mes développements”. Oui je vous l’accorde mais imaginez combien de temps vous perdriez à tester manuellement toute votre application après avoir fait des modifications pour vous assurer que tout marche correctement. Donc je pense que les tests ne sont que du bonheur!

Les étapes d’un bon test

Rien de plus simple, on écrit d’abord le test, il échoue et on écrit le code de production qui le fait passer.

Gotcha, vous avez tout compris! Mais ce que font beaucoup de développeurs y compris moi c’est:

  1. Ecrire le test
  2. Regarder le test échouer (rouge)
  3. Ecrire la logique, le plus simplement possible
  4. Passer le test (vert)
  5. Faire du “refractoring” (enlever les duplications, rendre meilleur le code)
  6. Reéxecuter le test pour voir si les modifications n’ont pas cassé le code

Conclusion

Voici une rapide introduction sur les tests unitaires et le Test-Driven Development. Il reste tout un tas de trucs excitants à voir (assertions, mocks, stubs, acceptance test etc…). Rendez vous très bientôt pour la suite de cette série de tutos sur les tests. Vos réactions en commentaires ;)

About Bionik6

Hellllooo, c’est Ibrahima aka Bionik6, étudiant en informatique, Front-end/Back-end Web Developer, passionné des nouvelles technologies et plus particulièrement du Web dans tous ses états! J'adore créer de nouvelles choses "from the ground up" à l'aide des logiciels de la suite Adobe puis passer au code. J'adore coder bien entendu, écouter de la bonne zik pop, rock, country et discuter avec des amis qui partagent la même passion. @ plushe pour de nouveaux articles et que la force soit avec vous, moi je file coder ;)

8 Comments

Laisser un commentaire

Facebook