tag:blogger.com,1999:blog-17256797.post114650567924933903..comments2008-12-19T19:28:48.309+01:00Carl Seleborghttp://www.blogger.com/profile/01901167627044872421noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-17256797.post-1149049997671950602006-05-31T06:33:00.000+02:002006-05-31T06:33:00.000+02:00Je relisais tout le code qu'écrivait la stagiaire, c'est comme cela que j'ai vu le "piège". La fonction devait valider la forme d'une chaîne de caractères ; pour rendre les tests plus complets, j'ai donc testé avec une plus grande gamme de chaînes de caractères valides (et non valides).<BR/><BR/>Votre seconde question est assez pertinente : si nous n'avions pas écrit les tests avant, nous aurions dû faire autrement pour nous assurer qu'ils fonctionnent. Le moyen équivalent aurait été d'écrire exactement les même tests, mais après les fonctions testées. Dans ce cas, le code aurait sans aucun doute été plus complexe. Rappelez-vous : la consigne était aussi de s'arrêter dès que les tests étaient bons. Cela signifie qu'on fait au plus simple.<BR/><BR/>Il faut bien choisir ses tests, afin de valider chaque fonction et chaque objet avec un ensemble pertinent de valeurs. C'est vraiment la qualité de ces valeurs qui importe, pas leur quantité. Et la bonne surprise, c'est que pendant qu'on réfléchit à toutes ces valeurs importantes qu'il faut essayer, avec toutes leurs variations pertinentes, on découvre en général beaucoup de cas auxquels on n'avait pas pensé spontanément!<BR/><BR/>Enfin, les tests unitaires permettent de choisir le degré d'assurance qu'on souhaite avoir quant au bon fonctionnement d'une partie de code. Pour peu que vos valeurs de test soient bien choisies, plus vous ajoutez de tests, plus vous êtes sûr du code produit. Et dans bien des cas, vous pouvez finir par couvrir 100% des cas ; c'est alors que les tests sont complets.Carl Seleborghttp://www.blogger.com/profile/01901167627044872421noreply@blogger.comtag:blogger.com,1999:blog-17256797.post-1149015286303035912006-05-30T20:54:00.000+02:002006-05-30T20:54:00.000+02:00"Bien sûr, je me suis fait avoir. Pour l'une des fonctions, j'avais écrit un test un peu trop simpliste, et la fonction qui en résulta fut très simpliste aussi."<BR/><BR/>La partie intéressante, c'est de savoir comment a été découvert que le test était trop simpliste et ce qu'ont apporté les tests supplémentaires qui, je suppose, ont été rajoutés.<BR/><BR/>Si le développement n'avait pas été dirigé par les tests (si les tests avaient été écrits après le code), le code produit aurait-il été suffisamment simple pour se rendre compte qu'il manquait des tests ?<BR/><BR/>Si des tests plus précis n'avaient pas été rajoutés, le résultat final aurait-il été aussi bon ?<BR/><BR/>Finalement, est-ce que le fait d'écrire, dans un premier temps, un test "trop" simple n'a pu être une force dans le sens où cela a peut être permis de rajouter les tests nécessaires pour arriver à un code plus robuste ?Oazhttp://agilitateur.azeau.com/noreply@blogger.com