<< Je voulai dire que le test unitaire n'attrapent en général que les bugs triviaux: on sait ce que doit faire une fonction/un groupe de fonctions dans telle situation, et elle ne le font pas, c'est un bug.
>>
C'est un stereotype courant. Tout depend bien sur de l'attention que tu portes a tes test unitaires. Mais si tu lis les bouquins sur XP, tu verras que dans les exemples, ils testent toujours les conditions limites.
Si je devais ecrire un test pour strcmp, je ne commencerai pas par verifier que srcmp("toto","toto") renvoie 0. Je commencerai par verifier que strcmp( NULL, "toto" ) ne plante pas, ainsi que strmp( NULL, NULL) et strcmp( "toto", NULL).
Il est evident qu'on ne peut pas penser a toutes les situations dans les tests unitaires. Mais il est parfois bien plus facile de simuler des situations tordues via des tests unitaires que via le logiciel, et donc de trouver des bugs subtils. Je l'ai vu dans la pratique, avec des situations que j'ai cree de toute piece sous forme de test, que je n'aurai jamais pu trouver dans la pratique.
Dans l'exemple que tu donnes, une URL tordue dans apache. Ok, le test unitaire initial ne contenait pas ce cas. Une fois le bug reporte, tu modifies le test unitaires pour inclure un certain nombre d'url tordues. Et c'est beaucoup plus facile a faire que d'essayre de rentrer les url tordues dans apache.
En ce qui concerne les tests de securite et de buffer overflow, en general, ces problemes sont adresses par des regles de codage et de conception plus que par des tests unitaires.
> non aux attendues du developpeur (tests unitaires).
Les bon developpeurs ont des attentes tres tres pessimistes sur leurs entrees et vont le refleter dans leur test.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
>>
C'est un stereotype courant. Tout depend bien sur de l'attention que tu portes a tes test unitaires. Mais si tu lis les bouquins sur XP, tu verras que dans les exemples, ils testent toujours les conditions limites.
Si je devais ecrire un test pour strcmp, je ne commencerai pas par verifier que srcmp("toto","toto") renvoie 0. Je commencerai par verifier que strcmp( NULL, "toto" ) ne plante pas, ainsi que strmp( NULL, NULL) et strcmp( "toto", NULL).
Il est evident qu'on ne peut pas penser a toutes les situations dans les tests unitaires. Mais il est parfois bien plus facile de simuler des situations tordues via des tests unitaires que via le logiciel, et donc de trouver des bugs subtils. Je l'ai vu dans la pratique, avec des situations que j'ai cree de toute piece sous forme de test, que je n'aurai jamais pu trouver dans la pratique.
Dans l'exemple que tu donnes, une URL tordue dans apache. Ok, le test unitaire initial ne contenait pas ce cas. Une fois le bug reporte, tu modifies le test unitaires pour inclure un certain nombre d'url tordues. Et c'est beaucoup plus facile a faire que d'essayre de rentrer les url tordues dans apache.
En ce qui concerne les tests de securite et de buffer overflow, en general, ces problemes sont adresses par des regles de codage et de conception plus que par des tests unitaires.
> non aux attendues du developpeur (tests unitaires).
Les bon developpeurs ont des attentes tres tres pessimistes sur leurs entrees et vont le refleter dans leur test.