C'est pas mal comme liste. Mais quand on a un budget limité et que l'on ne peut pas tout faire, il faut rechercher le plus efficace.
Les teste unitaires complet sont très contraignant, et peu utile. Par contre, les tests lié à un bug, qui doit de tout façon, doit être écrit pour le corriger, est utile pour éviter son retour.
Un truc qui est généralement interdit est de générer une sortie, vaguement vérifié puis d'utiliser des diffs. Cela ne permet pas de savoir si le code est correcte, cela permet de savoir si quelques choses à changer. En général, ce genre de test est simple à mettre en œuvre mais nécessite que le codeur sache que ce qu'il fait, que sa modification change la sortie de façon volontaire ou non. C'est plus un détecteur de changement, qu'un test.
Le test a ne pas oublier, et qui est indispensable, est le test de plus haut niveau : celui de l'utilisateur. En effet, beaucoup de bugs "unitaires" peuvent être masqué et n’impactent pas l’utilisateur final.
Dans le cas d'une GUI, il y a peu de chance que ses tests soient automatisables, et si ils le sont, la maintenance peut être prohibitif. Par contre, ce sont les tests qui ont le plus de valeur, car les client verront la même chose.
Ensuite, pour les programmes complexes, plutôt que des tests unitaires qui testeront finalement très peu les combinaisons des exigences, je préfère le fuzzing. Il s'agit de générer rapidement et aléatoirement des entrées plus ou moins fausse pour tester les réactions du programme. La condition de sorti est en général, simple : ne pas planter. Parfois, il est possible de faire plus compliquer. Un compilateur peut se faire injecter des programmes aléatoires, puis compiler le résultat avec et sans optimisation, l’exécution des 2 programmes doit avoir le même comportement.
# les tests qui marchent pour de vrai
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 3. Dernière modification le 15 janvier 2015 à 10:11.
C'est pas mal comme liste. Mais quand on a un budget limité et que l'on ne peut pas tout faire, il faut rechercher le plus efficace.
Les teste unitaires complet sont très contraignant, et peu utile. Par contre, les tests lié à un bug, qui doit de tout façon, doit être écrit pour le corriger, est utile pour éviter son retour.
Un truc qui est généralement interdit est de générer une sortie, vaguement vérifié puis d'utiliser des diffs. Cela ne permet pas de savoir si le code est correcte, cela permet de savoir si quelques choses à changer. En général, ce genre de test est simple à mettre en œuvre mais nécessite que le codeur sache que ce qu'il fait, que sa modification change la sortie de façon volontaire ou non. C'est plus un détecteur de changement, qu'un test.
Le test a ne pas oublier, et qui est indispensable, est le test de plus haut niveau : celui de l'utilisateur. En effet, beaucoup de bugs "unitaires" peuvent être masqué et n’impactent pas l’utilisateur final.
Dans le cas d'une GUI, il y a peu de chance que ses tests soient automatisables, et si ils le sont, la maintenance peut être prohibitif. Par contre, ce sont les tests qui ont le plus de valeur, car les client verront la même chose.
Ensuite, pour les programmes complexes, plutôt que des tests unitaires qui testeront finalement très peu les combinaisons des exigences, je préfère le fuzzing. Il s'agit de générer rapidement et aléatoirement des entrées plus ou moins fausse pour tester les réactions du programme. La condition de sorti est en général, simple : ne pas planter. Parfois, il est possible de faire plus compliquer. Un compilateur peut se faire injecter des programmes aléatoires, puis compiler le résultat avec et sans optimisation, l’exécution des 2 programmes doit avoir le même comportement.
"La première sécurité est la liberté"