Description
Second épisode d'une longue série sur TDD, Entrons dans le vif avec une définition un peu plus "académique". Pour en discuter directement je vous donne rendez-vous sur mon blog, sur linkedin ou twitter @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, nous allons continuer la série TDD démarrée la semaine dernière. Dans cet épisode, je vous expliquais toute l'humilité et la patience nécessaires avant de plonger dans TDD. J'espère que ce disclaimer vous permettra de démarrer du bon pied, et avec votre accord, sans transition, on va rentrer dès maintenant dans le vif du sujet. Qu'est-ce que TDD ? TDD est un acronyme pour Test Driven Development. Mon bel accent franglais. Ou en français, le développement piloté par les tests. En quoi est-ce que ça consiste ? Vous avez probablement entendu parler du fait de coder les tests en premier, avant l'implémentation. Alors oui, ça fait clairement partie du processus, mais ça n'est pas une fin en soi. Ce qu'il faut tâcher de retenir de TDD, c'est que cette méthodologie va vous aider à faire émerger la conception au fur et à mesure des cas de tests qui vont être rajoutés. Comment ça se passe concrètement ? En trois étapes. La première, on écrit un test qui décrit un cas métier simple, le plus simple possible pour démarrer. Bien évidemment, à ce moment-là, le code ne compilera même pas puisque l'implémentation n'est pas faite. Ce test doit préciser le contexte d'utilisation de la fonctionnalité, effectuer son appel et finalement opérer la vérification que l'effet produit est le bon. Conceptuellement, on doit d'abord mettre notre système dans un état donné. lancer de notre traitement et vérifier que le nouvel état du système correspond à ce qui est attendu ou alors que la valeur renvoyée est la bonne. Prenons un exemple simple. Je vends en ligne des pièces mécaniques assez pointues. J'ai une pièce actuellement en stock. Si l'utilisateur l'ajoute à son panier, je dois pouvoir annoncer un délai d'expédition raccourci inférieur à 5 jours. Mon test va initialiser le stock de l'article, lancer la fonctionnalité d'ajout au panier et vérifier que dans le panier, la disponibilité de l'article est la bonne. C'est un exemple. A ce stade, évidemment, le test ne réussit pas. Le code ne compile même pas. On dit à ce moment-là que le test est au rouge. On passe ensuite à l'implémentation. D'abord, une implémentation vide. Déjà, au moins pour que le code compile. Mais le test sera toujours au rouge. A ce moment-là seulement, on implémente le code strictement minimum afin de faire réussir le test, qui du coup... Passe au vert. Attention sur le strictement minimum. Ça a son importance. Si on reprend notre exemple, la fonction d'ajout au panier n'aura aucune logique. Juste un retour, un return de l'article avec la bonne disponibilité, inférieur à 5 jours. Oui, mais tu sais bien qu'il va y avoir d'autres cas à traiter. Pourquoi tu ne mets pas un if déjà pour gérer ton cas actuel ? Et puis là, tout de suite ? Je ne dispose d'aucune boule de cristal me permettant de voir l'avenir. Je ne vais pas préjuger des futurs besoins avant de les avoir formalisés dans leur cas de test explicite. Cette vision de n'écrire que le code nécessaire et suffisant pour faire passer le test au vert peut sembler en contradiction avec ce qu'on apprend généralement en formation académique. On nous explique bien souvent qu'il faut penser aux prochaines évolutions et concevoir dès le départ notre code et notre architecture pour prévoir tous ces éléments. Lorsqu'on utilise TDD, on n'implémente que le code strictement nécessaire au traitement du cas spécifié dans le test. Toute tentative de prévoir de futurs cas pourra dès lors être considérée comme de l'over-engineering. At last, but not least, comme on dit. Dernière étape du TDD, souvent oubliée ou négligée quand on débute, c'est l'étape du refactoring. Maintenant que notre test est passé au vert, toutes les modifications de code qu'on pourra faire seront toujours couvertes par notre test. Tant que le test reste vert, on sait que le comportement n'est pas cassé. On va donc pouvoir prendre du recul sur notre implémentation et faire les ajustements qu'on estime nécessaires pour gagner en lisibilité, en maintenabilité. Les variables et méthodes sont-elles nommées comme il faut ? Les fonctions utilisées ont-elles bien une seule responsabilité ? Est-ce que j'ai eu des difficultés à ajouter mon nouveau cas ? Etc. On a généralement peu de choses à refactorer après le tout premier test quand on commence une feature. Mais dès le second, il est vraiment crucial de prendre du recul sur nos implémentations. A titre personnel, j'adore cette phase. Je la considère un peu comme l'hygiène du développement. Vous vous brossez les dents après le repas ? Vous vous lavez les mains après de passer aux toilettes ? Alors, vous nettoyez votre code avant de considérer que la fonctionnalité est terminée. Si la question du refactoring vous intéresse, j'en ai fait un article complet sur mon blog, et peut-être que j'y dédierai un épisode prochain sur le podcast. Bref, une fois ces trois étapes terminées, on peut recommencer en créant un nouveau test, pour spécifier un nouveau cas métier à traiter, et on repart pour un tour de rouge vers refacto, ou red, green, refactor dans la littérature anglophone. Avec ce processus, cette boucle, vous avez en substance la base de TDD. Et si ce processus a l'air plutôt simple de prime abord, il ne faut néanmoins pas le sous-estimer, surtout lorsqu'on a longtemps travaillé sans. Les automatismes ont la vie dure et basculer totalement sur ce mode ne se fera pas en une seule fois. D'autant plus si le projet sur lequel vous vous y essayez pour la première fois n'est pas déjà codé et architecturé pour y greffer simplement des tests unitaires. Pour faire vos premiers essais, le kata en coding dojo reste à mon sens le meilleur contexte pour vous familiariser avec cette méthodologie. Vous aurez dans cet espace tout loisir d'échouer absolument sans conséquence. Car comme je l'expliquais dans mon précédent épisode, Les résultats pourraient prendre du temps à se manifester, surtout si vous êtes dans un contexte technique peu évident et que vous manquez d'accompagnement. N'hésitez jamais à demander de l'aide, du coaching pour affronter ces phases difficiles. Et si je devais ne garder qu'un seul conseil, c'est de ne pas lâcher durant cette phase de transition dans votre méthodo, car une fois que vous y serez habitué, non seulement ça vous semblera totalement naturel, mais en plus vous vous demanderez comment vous faisiez avant et vous vous rendrez compte du niveau de stress quotidien. auquel vous vous soumettiez vous-même. Voilà en somme la définition que je souhaitais vous apporter de TDD. J'espère vous avoir donné envie de vous y plonger un petit peu et que cet épisode vous aura plu. Si vous avez des interrogations ou des éléments que vous souhaiteriez voir abordés dans de futurs épisodes, n'hésitez pas à venir m'en parler sur Twitter, LinkedIn, tous les liens sont dans la description. A bientôt pour un prochain épisode et d'ici là, geekez bien, codez bien !
Description
Second épisode d'une longue série sur TDD, Entrons dans le vif avec une définition un peu plus "académique". Pour en discuter directement je vous donne rendez-vous sur mon blog, sur linkedin ou twitter @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, nous allons continuer la série TDD démarrée la semaine dernière. Dans cet épisode, je vous expliquais toute l'humilité et la patience nécessaires avant de plonger dans TDD. J'espère que ce disclaimer vous permettra de démarrer du bon pied, et avec votre accord, sans transition, on va rentrer dès maintenant dans le vif du sujet. Qu'est-ce que TDD ? TDD est un acronyme pour Test Driven Development. Mon bel accent franglais. Ou en français, le développement piloté par les tests. En quoi est-ce que ça consiste ? Vous avez probablement entendu parler du fait de coder les tests en premier, avant l'implémentation. Alors oui, ça fait clairement partie du processus, mais ça n'est pas une fin en soi. Ce qu'il faut tâcher de retenir de TDD, c'est que cette méthodologie va vous aider à faire émerger la conception au fur et à mesure des cas de tests qui vont être rajoutés. Comment ça se passe concrètement ? En trois étapes. La première, on écrit un test qui décrit un cas métier simple, le plus simple possible pour démarrer. Bien évidemment, à ce moment-là, le code ne compilera même pas puisque l'implémentation n'est pas faite. Ce test doit préciser le contexte d'utilisation de la fonctionnalité, effectuer son appel et finalement opérer la vérification que l'effet produit est le bon. Conceptuellement, on doit d'abord mettre notre système dans un état donné. lancer de notre traitement et vérifier que le nouvel état du système correspond à ce qui est attendu ou alors que la valeur renvoyée est la bonne. Prenons un exemple simple. Je vends en ligne des pièces mécaniques assez pointues. J'ai une pièce actuellement en stock. Si l'utilisateur l'ajoute à son panier, je dois pouvoir annoncer un délai d'expédition raccourci inférieur à 5 jours. Mon test va initialiser le stock de l'article, lancer la fonctionnalité d'ajout au panier et vérifier que dans le panier, la disponibilité de l'article est la bonne. C'est un exemple. A ce stade, évidemment, le test ne réussit pas. Le code ne compile même pas. On dit à ce moment-là que le test est au rouge. On passe ensuite à l'implémentation. D'abord, une implémentation vide. Déjà, au moins pour que le code compile. Mais le test sera toujours au rouge. A ce moment-là seulement, on implémente le code strictement minimum afin de faire réussir le test, qui du coup... Passe au vert. Attention sur le strictement minimum. Ça a son importance. Si on reprend notre exemple, la fonction d'ajout au panier n'aura aucune logique. Juste un retour, un return de l'article avec la bonne disponibilité, inférieur à 5 jours. Oui, mais tu sais bien qu'il va y avoir d'autres cas à traiter. Pourquoi tu ne mets pas un if déjà pour gérer ton cas actuel ? Et puis là, tout de suite ? Je ne dispose d'aucune boule de cristal me permettant de voir l'avenir. Je ne vais pas préjuger des futurs besoins avant de les avoir formalisés dans leur cas de test explicite. Cette vision de n'écrire que le code nécessaire et suffisant pour faire passer le test au vert peut sembler en contradiction avec ce qu'on apprend généralement en formation académique. On nous explique bien souvent qu'il faut penser aux prochaines évolutions et concevoir dès le départ notre code et notre architecture pour prévoir tous ces éléments. Lorsqu'on utilise TDD, on n'implémente que le code strictement nécessaire au traitement du cas spécifié dans le test. Toute tentative de prévoir de futurs cas pourra dès lors être considérée comme de l'over-engineering. At last, but not least, comme on dit. Dernière étape du TDD, souvent oubliée ou négligée quand on débute, c'est l'étape du refactoring. Maintenant que notre test est passé au vert, toutes les modifications de code qu'on pourra faire seront toujours couvertes par notre test. Tant que le test reste vert, on sait que le comportement n'est pas cassé. On va donc pouvoir prendre du recul sur notre implémentation et faire les ajustements qu'on estime nécessaires pour gagner en lisibilité, en maintenabilité. Les variables et méthodes sont-elles nommées comme il faut ? Les fonctions utilisées ont-elles bien une seule responsabilité ? Est-ce que j'ai eu des difficultés à ajouter mon nouveau cas ? Etc. On a généralement peu de choses à refactorer après le tout premier test quand on commence une feature. Mais dès le second, il est vraiment crucial de prendre du recul sur nos implémentations. A titre personnel, j'adore cette phase. Je la considère un peu comme l'hygiène du développement. Vous vous brossez les dents après le repas ? Vous vous lavez les mains après de passer aux toilettes ? Alors, vous nettoyez votre code avant de considérer que la fonctionnalité est terminée. Si la question du refactoring vous intéresse, j'en ai fait un article complet sur mon blog, et peut-être que j'y dédierai un épisode prochain sur le podcast. Bref, une fois ces trois étapes terminées, on peut recommencer en créant un nouveau test, pour spécifier un nouveau cas métier à traiter, et on repart pour un tour de rouge vers refacto, ou red, green, refactor dans la littérature anglophone. Avec ce processus, cette boucle, vous avez en substance la base de TDD. Et si ce processus a l'air plutôt simple de prime abord, il ne faut néanmoins pas le sous-estimer, surtout lorsqu'on a longtemps travaillé sans. Les automatismes ont la vie dure et basculer totalement sur ce mode ne se fera pas en une seule fois. D'autant plus si le projet sur lequel vous vous y essayez pour la première fois n'est pas déjà codé et architecturé pour y greffer simplement des tests unitaires. Pour faire vos premiers essais, le kata en coding dojo reste à mon sens le meilleur contexte pour vous familiariser avec cette méthodologie. Vous aurez dans cet espace tout loisir d'échouer absolument sans conséquence. Car comme je l'expliquais dans mon précédent épisode, Les résultats pourraient prendre du temps à se manifester, surtout si vous êtes dans un contexte technique peu évident et que vous manquez d'accompagnement. N'hésitez jamais à demander de l'aide, du coaching pour affronter ces phases difficiles. Et si je devais ne garder qu'un seul conseil, c'est de ne pas lâcher durant cette phase de transition dans votre méthodo, car une fois que vous y serez habitué, non seulement ça vous semblera totalement naturel, mais en plus vous vous demanderez comment vous faisiez avant et vous vous rendrez compte du niveau de stress quotidien. auquel vous vous soumettiez vous-même. Voilà en somme la définition que je souhaitais vous apporter de TDD. J'espère vous avoir donné envie de vous y plonger un petit peu et que cet épisode vous aura plu. Si vous avez des interrogations ou des éléments que vous souhaiteriez voir abordés dans de futurs épisodes, n'hésitez pas à venir m'en parler sur Twitter, LinkedIn, tous les liens sont dans la description. A bientôt pour un prochain épisode et d'ici là, geekez bien, codez bien !
Share
Embed
You may also like
Description
Second épisode d'une longue série sur TDD, Entrons dans le vif avec une définition un peu plus "académique". Pour en discuter directement je vous donne rendez-vous sur mon blog, sur linkedin ou twitter @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, nous allons continuer la série TDD démarrée la semaine dernière. Dans cet épisode, je vous expliquais toute l'humilité et la patience nécessaires avant de plonger dans TDD. J'espère que ce disclaimer vous permettra de démarrer du bon pied, et avec votre accord, sans transition, on va rentrer dès maintenant dans le vif du sujet. Qu'est-ce que TDD ? TDD est un acronyme pour Test Driven Development. Mon bel accent franglais. Ou en français, le développement piloté par les tests. En quoi est-ce que ça consiste ? Vous avez probablement entendu parler du fait de coder les tests en premier, avant l'implémentation. Alors oui, ça fait clairement partie du processus, mais ça n'est pas une fin en soi. Ce qu'il faut tâcher de retenir de TDD, c'est que cette méthodologie va vous aider à faire émerger la conception au fur et à mesure des cas de tests qui vont être rajoutés. Comment ça se passe concrètement ? En trois étapes. La première, on écrit un test qui décrit un cas métier simple, le plus simple possible pour démarrer. Bien évidemment, à ce moment-là, le code ne compilera même pas puisque l'implémentation n'est pas faite. Ce test doit préciser le contexte d'utilisation de la fonctionnalité, effectuer son appel et finalement opérer la vérification que l'effet produit est le bon. Conceptuellement, on doit d'abord mettre notre système dans un état donné. lancer de notre traitement et vérifier que le nouvel état du système correspond à ce qui est attendu ou alors que la valeur renvoyée est la bonne. Prenons un exemple simple. Je vends en ligne des pièces mécaniques assez pointues. J'ai une pièce actuellement en stock. Si l'utilisateur l'ajoute à son panier, je dois pouvoir annoncer un délai d'expédition raccourci inférieur à 5 jours. Mon test va initialiser le stock de l'article, lancer la fonctionnalité d'ajout au panier et vérifier que dans le panier, la disponibilité de l'article est la bonne. C'est un exemple. A ce stade, évidemment, le test ne réussit pas. Le code ne compile même pas. On dit à ce moment-là que le test est au rouge. On passe ensuite à l'implémentation. D'abord, une implémentation vide. Déjà, au moins pour que le code compile. Mais le test sera toujours au rouge. A ce moment-là seulement, on implémente le code strictement minimum afin de faire réussir le test, qui du coup... Passe au vert. Attention sur le strictement minimum. Ça a son importance. Si on reprend notre exemple, la fonction d'ajout au panier n'aura aucune logique. Juste un retour, un return de l'article avec la bonne disponibilité, inférieur à 5 jours. Oui, mais tu sais bien qu'il va y avoir d'autres cas à traiter. Pourquoi tu ne mets pas un if déjà pour gérer ton cas actuel ? Et puis là, tout de suite ? Je ne dispose d'aucune boule de cristal me permettant de voir l'avenir. Je ne vais pas préjuger des futurs besoins avant de les avoir formalisés dans leur cas de test explicite. Cette vision de n'écrire que le code nécessaire et suffisant pour faire passer le test au vert peut sembler en contradiction avec ce qu'on apprend généralement en formation académique. On nous explique bien souvent qu'il faut penser aux prochaines évolutions et concevoir dès le départ notre code et notre architecture pour prévoir tous ces éléments. Lorsqu'on utilise TDD, on n'implémente que le code strictement nécessaire au traitement du cas spécifié dans le test. Toute tentative de prévoir de futurs cas pourra dès lors être considérée comme de l'over-engineering. At last, but not least, comme on dit. Dernière étape du TDD, souvent oubliée ou négligée quand on débute, c'est l'étape du refactoring. Maintenant que notre test est passé au vert, toutes les modifications de code qu'on pourra faire seront toujours couvertes par notre test. Tant que le test reste vert, on sait que le comportement n'est pas cassé. On va donc pouvoir prendre du recul sur notre implémentation et faire les ajustements qu'on estime nécessaires pour gagner en lisibilité, en maintenabilité. Les variables et méthodes sont-elles nommées comme il faut ? Les fonctions utilisées ont-elles bien une seule responsabilité ? Est-ce que j'ai eu des difficultés à ajouter mon nouveau cas ? Etc. On a généralement peu de choses à refactorer après le tout premier test quand on commence une feature. Mais dès le second, il est vraiment crucial de prendre du recul sur nos implémentations. A titre personnel, j'adore cette phase. Je la considère un peu comme l'hygiène du développement. Vous vous brossez les dents après le repas ? Vous vous lavez les mains après de passer aux toilettes ? Alors, vous nettoyez votre code avant de considérer que la fonctionnalité est terminée. Si la question du refactoring vous intéresse, j'en ai fait un article complet sur mon blog, et peut-être que j'y dédierai un épisode prochain sur le podcast. Bref, une fois ces trois étapes terminées, on peut recommencer en créant un nouveau test, pour spécifier un nouveau cas métier à traiter, et on repart pour un tour de rouge vers refacto, ou red, green, refactor dans la littérature anglophone. Avec ce processus, cette boucle, vous avez en substance la base de TDD. Et si ce processus a l'air plutôt simple de prime abord, il ne faut néanmoins pas le sous-estimer, surtout lorsqu'on a longtemps travaillé sans. Les automatismes ont la vie dure et basculer totalement sur ce mode ne se fera pas en une seule fois. D'autant plus si le projet sur lequel vous vous y essayez pour la première fois n'est pas déjà codé et architecturé pour y greffer simplement des tests unitaires. Pour faire vos premiers essais, le kata en coding dojo reste à mon sens le meilleur contexte pour vous familiariser avec cette méthodologie. Vous aurez dans cet espace tout loisir d'échouer absolument sans conséquence. Car comme je l'expliquais dans mon précédent épisode, Les résultats pourraient prendre du temps à se manifester, surtout si vous êtes dans un contexte technique peu évident et que vous manquez d'accompagnement. N'hésitez jamais à demander de l'aide, du coaching pour affronter ces phases difficiles. Et si je devais ne garder qu'un seul conseil, c'est de ne pas lâcher durant cette phase de transition dans votre méthodo, car une fois que vous y serez habitué, non seulement ça vous semblera totalement naturel, mais en plus vous vous demanderez comment vous faisiez avant et vous vous rendrez compte du niveau de stress quotidien. auquel vous vous soumettiez vous-même. Voilà en somme la définition que je souhaitais vous apporter de TDD. J'espère vous avoir donné envie de vous y plonger un petit peu et que cet épisode vous aura plu. Si vous avez des interrogations ou des éléments que vous souhaiteriez voir abordés dans de futurs épisodes, n'hésitez pas à venir m'en parler sur Twitter, LinkedIn, tous les liens sont dans la description. A bientôt pour un prochain épisode et d'ici là, geekez bien, codez bien !
Description
Second épisode d'une longue série sur TDD, Entrons dans le vif avec une définition un peu plus "académique". Pour en discuter directement je vous donne rendez-vous sur mon blog, sur linkedin ou twitter @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, nous allons continuer la série TDD démarrée la semaine dernière. Dans cet épisode, je vous expliquais toute l'humilité et la patience nécessaires avant de plonger dans TDD. J'espère que ce disclaimer vous permettra de démarrer du bon pied, et avec votre accord, sans transition, on va rentrer dès maintenant dans le vif du sujet. Qu'est-ce que TDD ? TDD est un acronyme pour Test Driven Development. Mon bel accent franglais. Ou en français, le développement piloté par les tests. En quoi est-ce que ça consiste ? Vous avez probablement entendu parler du fait de coder les tests en premier, avant l'implémentation. Alors oui, ça fait clairement partie du processus, mais ça n'est pas une fin en soi. Ce qu'il faut tâcher de retenir de TDD, c'est que cette méthodologie va vous aider à faire émerger la conception au fur et à mesure des cas de tests qui vont être rajoutés. Comment ça se passe concrètement ? En trois étapes. La première, on écrit un test qui décrit un cas métier simple, le plus simple possible pour démarrer. Bien évidemment, à ce moment-là, le code ne compilera même pas puisque l'implémentation n'est pas faite. Ce test doit préciser le contexte d'utilisation de la fonctionnalité, effectuer son appel et finalement opérer la vérification que l'effet produit est le bon. Conceptuellement, on doit d'abord mettre notre système dans un état donné. lancer de notre traitement et vérifier que le nouvel état du système correspond à ce qui est attendu ou alors que la valeur renvoyée est la bonne. Prenons un exemple simple. Je vends en ligne des pièces mécaniques assez pointues. J'ai une pièce actuellement en stock. Si l'utilisateur l'ajoute à son panier, je dois pouvoir annoncer un délai d'expédition raccourci inférieur à 5 jours. Mon test va initialiser le stock de l'article, lancer la fonctionnalité d'ajout au panier et vérifier que dans le panier, la disponibilité de l'article est la bonne. C'est un exemple. A ce stade, évidemment, le test ne réussit pas. Le code ne compile même pas. On dit à ce moment-là que le test est au rouge. On passe ensuite à l'implémentation. D'abord, une implémentation vide. Déjà, au moins pour que le code compile. Mais le test sera toujours au rouge. A ce moment-là seulement, on implémente le code strictement minimum afin de faire réussir le test, qui du coup... Passe au vert. Attention sur le strictement minimum. Ça a son importance. Si on reprend notre exemple, la fonction d'ajout au panier n'aura aucune logique. Juste un retour, un return de l'article avec la bonne disponibilité, inférieur à 5 jours. Oui, mais tu sais bien qu'il va y avoir d'autres cas à traiter. Pourquoi tu ne mets pas un if déjà pour gérer ton cas actuel ? Et puis là, tout de suite ? Je ne dispose d'aucune boule de cristal me permettant de voir l'avenir. Je ne vais pas préjuger des futurs besoins avant de les avoir formalisés dans leur cas de test explicite. Cette vision de n'écrire que le code nécessaire et suffisant pour faire passer le test au vert peut sembler en contradiction avec ce qu'on apprend généralement en formation académique. On nous explique bien souvent qu'il faut penser aux prochaines évolutions et concevoir dès le départ notre code et notre architecture pour prévoir tous ces éléments. Lorsqu'on utilise TDD, on n'implémente que le code strictement nécessaire au traitement du cas spécifié dans le test. Toute tentative de prévoir de futurs cas pourra dès lors être considérée comme de l'over-engineering. At last, but not least, comme on dit. Dernière étape du TDD, souvent oubliée ou négligée quand on débute, c'est l'étape du refactoring. Maintenant que notre test est passé au vert, toutes les modifications de code qu'on pourra faire seront toujours couvertes par notre test. Tant que le test reste vert, on sait que le comportement n'est pas cassé. On va donc pouvoir prendre du recul sur notre implémentation et faire les ajustements qu'on estime nécessaires pour gagner en lisibilité, en maintenabilité. Les variables et méthodes sont-elles nommées comme il faut ? Les fonctions utilisées ont-elles bien une seule responsabilité ? Est-ce que j'ai eu des difficultés à ajouter mon nouveau cas ? Etc. On a généralement peu de choses à refactorer après le tout premier test quand on commence une feature. Mais dès le second, il est vraiment crucial de prendre du recul sur nos implémentations. A titre personnel, j'adore cette phase. Je la considère un peu comme l'hygiène du développement. Vous vous brossez les dents après le repas ? Vous vous lavez les mains après de passer aux toilettes ? Alors, vous nettoyez votre code avant de considérer que la fonctionnalité est terminée. Si la question du refactoring vous intéresse, j'en ai fait un article complet sur mon blog, et peut-être que j'y dédierai un épisode prochain sur le podcast. Bref, une fois ces trois étapes terminées, on peut recommencer en créant un nouveau test, pour spécifier un nouveau cas métier à traiter, et on repart pour un tour de rouge vers refacto, ou red, green, refactor dans la littérature anglophone. Avec ce processus, cette boucle, vous avez en substance la base de TDD. Et si ce processus a l'air plutôt simple de prime abord, il ne faut néanmoins pas le sous-estimer, surtout lorsqu'on a longtemps travaillé sans. Les automatismes ont la vie dure et basculer totalement sur ce mode ne se fera pas en une seule fois. D'autant plus si le projet sur lequel vous vous y essayez pour la première fois n'est pas déjà codé et architecturé pour y greffer simplement des tests unitaires. Pour faire vos premiers essais, le kata en coding dojo reste à mon sens le meilleur contexte pour vous familiariser avec cette méthodologie. Vous aurez dans cet espace tout loisir d'échouer absolument sans conséquence. Car comme je l'expliquais dans mon précédent épisode, Les résultats pourraient prendre du temps à se manifester, surtout si vous êtes dans un contexte technique peu évident et que vous manquez d'accompagnement. N'hésitez jamais à demander de l'aide, du coaching pour affronter ces phases difficiles. Et si je devais ne garder qu'un seul conseil, c'est de ne pas lâcher durant cette phase de transition dans votre méthodo, car une fois que vous y serez habitué, non seulement ça vous semblera totalement naturel, mais en plus vous vous demanderez comment vous faisiez avant et vous vous rendrez compte du niveau de stress quotidien. auquel vous vous soumettiez vous-même. Voilà en somme la définition que je souhaitais vous apporter de TDD. J'espère vous avoir donné envie de vous y plonger un petit peu et que cet épisode vous aura plu. Si vous avez des interrogations ou des éléments que vous souhaiteriez voir abordés dans de futurs épisodes, n'hésitez pas à venir m'en parler sur Twitter, LinkedIn, tous les liens sont dans la description. A bientôt pour un prochain épisode et d'ici là, geekez bien, codez bien !
Share
Embed
You may also like