Alors, comment testerais-tu que la fonction "square" marche bien? C'est quoi le test "pas stupide" à mettre en place?
Maths (métamaths incluses) ou logique, si les tests unitaires couvrent N cas élémentaires distincts quels qu'ils soient, ils ne peuvent prouver le bon fonctionnement de l'élément testé que si ces N cas recouvrent tous les cas d'entrée de l'objet testé. En d'autres mots, le test unitaire doit tester chaque type d'entrée, puisque s'il ne le fait pas, une méthode qui répond uniquement aux N tests sera validée.
En d'autres mots, restons sur la logique, la méthode des tests unitaire n'est pas suffisante pour montrer le bon fonctionnement de la classe: "test unitaire validé" n'implique pas "classe validée". Elle n'est même pas nécessaire: à partir du seul code source, sans test, on peut prouver le bon ou mauvais fonctionnement de la méthode/fonction/classe.
Alors pourquoi se baser sur le test unitaire pour en déduire que la classe marche (dans l'absolue) ou qu'après modification du code de la classe, celle-ci marche toujours.
Avec ou sans effet de bord, qu'est ce qui rentre dans la catégorie "trivial"? As-tu un exemple de classe + classe de test qui serait pertinent?
Pourquoi ne pas changer d'approche? au lieu de joindre une classe de test (qui teste des cas précis et non tous les cas), on joindrai un "bout de papier", qui prouverait logiquement (ou mathématiquement) que la classe marche. Une preuve qui, somme toute, dit non pas "ma classe de test a mis en avant que square(x)=x² pour x=1, -1, 7, 4.6" mais "l'étude de mon code source me permet de prouver que square(x)=x² pour tout x entier de valeur absolue compris entre +- (2^16)-1"?
Maths (métamaths incluses) ou logique, si les tests unitaires couvrent N cas élémentaires distincts quels qu'ils soient, ils ne peuvent prouver le bon fonctionnement de l'élément testé que si ces N cas recouvrent tous les cas d'entrée de l'objet testé. En d'autres mots, le test unitaire doit tester chaque type d'entrée, puisque s'il ne le fait pas, une méthode qui répond uniquement aux N tests sera validée.
En d'autres mots, restons sur la logique, la méthode des tests unitaire n'est pas suffisante pour montrer le bon fonctionnement de la classe: "test unitaire validé" n'implique pas "classe validée". Elle n'est même pas nécessaire: à partir du seul code source, sans test, on peut prouver le bon ou mauvais fonctionnement de la méthode/fonction/classe.
Alors pourquoi se baser sur le test unitaire pour en déduire que la classe marche (dans l'absolue) ou qu'après modification du code de la classe, celle-ci marche toujours.
Avec ou sans effet de bord, qu'est ce qui rentre dans la catégorie "trivial"? As-tu un exemple de classe + classe de test qui serait pertinent?
Pourquoi ne pas changer d'approche? au lieu de joindre une classe de test (qui teste des cas précis et non tous les cas), on joindrai un "bout de papier", qui prouverait logiquement (ou mathématiquement) que la classe marche. Une preuve qui, somme toute, dit non pas "ma classe de test a mis en avant que square(x)=x² pour x=1, -1, 7, 4.6" mais "l'étude de mon code source me permet de prouver que square(x)=x² pour tout x entier de valeur absolue compris entre +- (2^16)-1"?