En pratique, quand tu écris tes tests en même que ton code (je te conseille de regarder ce qu'est le Test Driven Development) tu es rapidement plus productif qu'en écrivant ton code et en le testant ensuite "à la main". Lorsque tu dois écrire une fonction un peu 'poilue' (avec 2 "if else" consécutifs par exemple tu as déjà 4 cas à vérifier), repasser tous les cas manuellement prend énormément de temps ; ceci dit c'est encore plus long au final lorsque c'est ton client qui tombe sur le bug, met 3 heures à mal te le décrire au téléphone, que tu passes 1h à essayer de le reproduire, puis 3h à corriger ton code d'il y a 6 mois en priant de ne pas faire de régression. Alors que rejouer tes tests sur ladite fonction prend 2 secondes, et tu peux donc les rejouer entre chaque modifications pendant que tu codes ta fonction.
Il y a quelques années, j'ai codé, en TDD, 30K lignes de code en 1 an et demi (+ 45K lignes de tests). Pendant la même période, mon collègue qui travaillait sur le me logiciel, et qui testait à la main avait fait 18K lignes, et 95% des bugs qui remontaient étaient chez lui.
J'aimerai aussi l'avis d'un codeur pratiquant le Contract Driven Development ; ne l'ayant jamais pratiqué moi même je peux me tromper, mais a priori je trouve assez simple d'écrire les tests pour une fonction de tri par exemple ça pourrait donner:
ce qui es quand même très simple. Alors que par contrat, j'imagine qu'il faut tester que ton résultat contient tous tes éléments de départ, et uniquement ceux-là, et vérifier qu'ils sont correctement ordonnés. Ça me semble plus pénible à écrire.
[^] # Re: Pas de révision d'historique
Posté par GuieA_7 (site web personnel) . En réponse au journal Chiselapp ferme ses portes. Évalué à 1.
En pratique, quand tu écris tes tests en même que ton code (je te conseille de regarder ce qu'est le Test Driven Development) tu es rapidement plus productif qu'en écrivant ton code et en le testant ensuite "à la main". Lorsque tu dois écrire une fonction un peu 'poilue' (avec 2 "if else" consécutifs par exemple tu as déjà 4 cas à vérifier), repasser tous les cas manuellement prend énormément de temps ; ceci dit c'est encore plus long au final lorsque c'est ton client qui tombe sur le bug, met 3 heures à mal te le décrire au téléphone, que tu passes 1h à essayer de le reproduire, puis 3h à corriger ton code d'il y a 6 mois en priant de ne pas faire de régression. Alors que rejouer tes tests sur ladite fonction prend 2 secondes, et tu peux donc les rejouer entre chaque modifications pendant que tu codes ta fonction.
Il y a quelques années, j'ai codé, en TDD, 30K lignes de code en 1 an et demi (+ 45K lignes de tests). Pendant la même période, mon collègue qui travaillait sur le me logiciel, et qui testait à la main avait fait 18K lignes, et 95% des bugs qui remontaient étaient chez lui.
J'aimerai aussi l'avis d'un codeur pratiquant le Contract Driven Development ; ne l'ayant jamais pratiqué moi même je peux me tromper, mais a priori je trouve assez simple d'écrire les tests pour une fonction de tri par exemple ça pourrait donner:
ce qui es quand même très simple. Alors que par contrat, j'imagine qu'il faut tester que ton résultat contient tous tes éléments de départ, et uniquement ceux-là, et vérifier qu'ils sont correctement ordonnés. Ça me semble plus pénible à écrire.