Cet article contient un bonus téléchargeable (voir à la fin de l’article)
Dans cet article, je vous présente une méthode pour coder plus vite et donc gagner en productivité dans vos développements. Elle permet aussi d’améliorer la qualité de vos logiciels. La méthode est simple à mettre en oeuvre en 4 étapes.
Coder plus vite vous permettra, par exemple, de mieux respecter les délais et surtout d’être plus serein. Fini les journées qui se terminent à 22h !
Habituellement, lorsque vous développez un morceau de code, vous commencez par écrire le code et puis vous lancer votre application pour vérifier si ce que vous avez écrit fonctionne comme il faut.
Si c’est bon, vous enregistrez votre projet et passez à la tache suivante.
Sinon, vous corrigez le comportement.
Cette méthode de travail est la méthode classique que l’on apprend généralement à l’école.
Néanmoins, elle pose plusieurs problèmes :
- lorsque vous testez, vous testez l’intégralité de votre application et donc pas uniquement le code que vous venez d’écrire (risque d’effets de bords)
- les tests sont manuels et longs car il faut sans cesse démarrer l’application complètement et arriver au niveau de la fonctionnalité à tester,
- les tests sont faits à la main et sont donc fastidieux et peu intéressants.
Comment coder plus vite ?
Il y a quelques années, je me suis posé la question pour savoir comment faire autrement. J’ai donc fait des recherches sur les différentes méthodes de développement, j’ai lu beaucoup sur le sujet.
Aujourd’hui, je ne travaille plus du tout comme ça.
La méthode de travail que j’utilise me permet de développer plus vite et surtout de ne pas avoir à lancer l’application complète mille fois par jour (à chaque fois que je change une virgule dans le code).
La méthode simple pour coder plus vite
La méthode dont je vous parle est basée sur TDD (Test Driven Development). Il s’agit d’une méthode de travaille qui préconise de commencer par écrire les tests unitaires avant de développer une fonctionnalité.
Au quotidien, j’ai simplifié cette méthode pour la rendre plus accessible et moins contraignante.
Voici ce que je fais lorsque je développe un nouveau module ou une fonctionnalité :
- Je commence par écrire le minimum de code nécessaire,
- Je réfléchie ensuite à une manière de la tester grâce à des tests unitaires. J’écris donc des tests pour vérifier qu’elle fonctionne.
- Je fais toujours du refactoring pour, au minimum, extraire le code et créer des méthodes communes afin d’éviter à tout prix le code dupliqué,
- Après le refactoring, je relance les tests pour vérifier que ça fonctionne toujours.
Cette méthode est très proche de TDD à une exception près : je ne commence pas par les tests unitaires.
La méthode fonctionne
Cette méthode fonctionne et vous fait vraiment gagner du temps. Voici pourquoi :
- avant : vous lancez votre application web, vous cliquez la où il faut pour afficher sur l’écran que vous souhaitez tester. Vous faites les saisies nécessaires et vérifiez le résultat « à la main ». Un cycle de test vous prend au minimum 1 minute (vraiment au minimum).
- avec la méthode TDD simplifiée, vous utilisez des tests unitaires automatisables, il suffit de quelques seconde pour lancer votre test et en vérifier le résultat. De plus, grâce aux tests qui s’exécutent de manière automatique, vous n’avez plus besoin de cliquer partout pour arriver à votre formulaire à tester.
- et en bonus, grâce aux tests unitaires et aux tests de couverture, vous pouvez prouvez le pourcentage de code réellement testé dans votre application. Pouvez-vous en faire autant avec une méthode « à la main » ?
La plan d’action
Pour passer à l’action, je vous propose tout simplement de l’essayer et d’en vérifier le résultat.
Je vous ai préparé une fiche complémentaire qui décrit exactement comment passer à l’action. Elle est téléchargeable juste en dessous de l’article (il suffit de partager pour débloquer le lien).
[/sociallocker]
J’aime bien l’idée de commencer par écrire le minimum de code nécessaire avant d’écrire les tests unitaires parce que lorsque l’on développe une fonctionnalité c’est vraiment dure voir impossible d’anticiper les différentes méthodes qu’on l’on va devoir écrire sans en oublier une alors que si l’on commence par poser l’architecture sans pour autant implémenter complètement les différentes méthodes/classes ça change tout et là c’est beaucoup plus simple d’écrire ses tests unitaires.
Ce sujet m’intéresse autant sur le plan technique sur le plan gestion de projet. En effet les développeurs sont souvent réfractaire à écrire des tests unitaires il le font souvent par obligation que par envie. Comment les motivés par exemple ?
Merci Jean-Baptiste.
Effectivement, l’idée est de commencer « petit » par le minimum nécessaire. Ce principe m’a aussi séduit au début.
Pour se motiver, il suffit d’essayer et de s’y prendre au jeu. A force de pratique, je n’ai quasiment plus envie d’utiliser l’ancienne méthode car les tests unitaires me rassurent. Je sais ce qui est vraiment testé. Je sais que ça fonctionne comme je le décris dans mes tests et ça me permet de faire du refactoring en toute tranquilité.
Bonjour,
Déjà merci pour votre article. C’est toujours intéressant de découvrir tous les jours de nouvelles façons de travailler.
Bien que je trouve alléchante votre initiative de « coller » au maximum au TDD, en essayant de réduire l’aspect contraignant de cette méthode, je ne suis pas certain que la qualité du test proposé soit qualitativement égale à la méthode « manuelle ».
Je m’explique : vous comparer un test manuel (donc fonctionnel) à l’exécution d’une suite de tests unitaires automatisée. Loin de moi l’idée de critiquer le test unitaire en soit, je pense que nous sommes tous d’accord pour dire qu’il est important. Mais le test unitaire … reste un test unitaire, et n’est en rien comparable à une suite de tests fonctionnels, qu’elle soit exécutée de façon automatisée ou manuelle.
Le test unitaire permet de tester une classe/méthode de façon isolée, en dehors de tout contexte d’intégration (le test ne sort jamais de la fonction testée, et tous les appels extérieurs sont sensés être mockés).
Le test manuel (fonctionnel) consiste à valider le comportement de l’application dans son ensemble. On pourrait l’assimiler également à un test d’intégration à plus haut niveau.
Un exemple simple montrant les différence des deux approches : la suite de tests unitaire peux s’exécuter avec succès (« les classes ont des comportements valides en tant que tel »), mais l’application ne fonctionne pas comme voulue dans son ensemble (« les classes ne sont pas utilisées correctement »).
Il est donc important s’il on veut automatiser le tout de marier tests unitaires & tests fonctionnels (aussi que d’autre type de tests, en fonction du domaine et de la motivation de l’équipe : tests d’intégration, tests d’acceptation, tests de charge etc…).
Pour finir, je dirait également que la couverture du code par les tests unitaire ne représente pas forcément un indicateur de qualité incontesté.
Prendre 5 heures cumulées de son temps pour écrire des tests sur des accésseurs (setter/getter) afin d’obtenir un code coverrage de 100% représente plus une perte de temps, temps qui aurait pu être utilisé pour enrichir les cas des autres suites de tests unitaires, voir justement commencer à mettre en place les tests fonctionnels automatisés 😉
Cependant, merci pour avoir confié votre approche sur ce site, elle reste tout de même très intéressante.
Bonsoir Sylvain et tout d’abord merci pour ton commentaire très constructif (surement le plus long sur ce blog !).
Je comprends tout à fait votre point de vue sur la qualité du test.
Je souhaite simplement compléter mes propos : en fait, l’idée était surtout de montrer que l’on peut développer plus vite grâce à TDD ou à sa version simplifiée.
L’idée est bien de vérifier le fonctionnement d’une partie de code sans avoir à redémarrer l’application à chaque fois.
Je le constate tous les jours, je vois beaucoup de développeurs qui ne « connaissent » pas d’autre manière que de lancer l’appli à la main. Or, si le dev le fait 100 fois par jours, c’est beaucoup de temps perdu (selon moi).
Bien sûr les tests unitaires ne sont qu’une partie de ce qu’il faut pour valider la qualité d’une application. Mais franchement, j’ai travaillé pour des dizaines de clients et à chaque fois le client me dit qu’il n’y a pas de tests (aucun test, « ils sont faits à la main »). Le problème est donc simple : que se passe-t-il quand le développeur quitte la société ou s’il est tout simplement absent. Qui va tester l’application ?
Bref, il est clair que les tests d’intégration et les tests fonctionnels sont bien sûr nécessaires. Je dirais que les tests unitaires sont une première étape pour améliorer la qualité (et surtout automatiser).