Par "preuve", j'entends une démonstration exacte et exhaustive, basée sur la lecture et la compréhension du code source; ce qui est assimilable à une preuve (démonstration) mathématique, où les hypothèses sont le code source.
Je n'ai pas d'exemple en entreprise, seulement en école. Il fallait non seulement concevoir le projet (UML) et l'implémenter (comme à peu près partout je suppose), mais également, prouver que l'algorithme et les méthodes sont fiables (à grand coups de "quelque soit l'entrée X blablabla").
Bah, alors si les tests ne sont pas là pour prouver qu'un code marche, ils sont là pour quoi? Pourquoi n'aurai-je pas de clients? Entre "eh, j'ai fait des tests, et cela marche, mais pour les 99.999% des cas non testés, ben je ne sais pas trop" et "mon architecte, avec l'aide du mathématicien, ont démontré que le code marchera toujours", y'a une sacrée marge, non? Il a quand même une notion de garantie dans la démonstration (ou preuve) que je ne retrouve pas dans le test simple.
Pas faux, n'ayant pas donné de spécif, preuve ou test n'ont aucun sens. J'ai justement induis que plus() devait sommer deux nombres et renvoyer leur somme, j'ai fais exactement la même chose qu'un test qui induirait que la fonction marche.
Et tu te dis peut-être que la preuve mettrai des mois ou des années à se faire... C'est peut-être juste un manque de pratique
iffle: De toute façon, dans tous les cas, ma preuve une fois faite est terminée et enterrée, tandis qu'avec l'approche des tests, il faut de façon continue "surveiller" et corriger le système. Le test a une sorte d'approche "blacklist" là où la preuve est plus "whitelist".
Après, ok, ce qui m'échappe peut être c'est l'approche "informatique technique", où un truc boiteux vaut mieux que prendre le temps de faire un truc robuste...
Belle trouvaille que ce lien, niahoo. D'ailleurs, sur des systèmes parallèles, vous vous fiez là encore à des simples "tests"?!
/PS
Je n'ai pas d'exemple en entreprise, seulement en école. Il fallait non seulement concevoir le projet (UML) et l'implémenter (comme à peu près partout je suppose), mais également, prouver que l'algorithme et les méthodes sont fiables (à grand coups de "quelque soit l'entrée X blablabla").
Bah, alors si les tests ne sont pas là pour prouver qu'un code marche, ils sont là pour quoi? Pourquoi n'aurai-je pas de clients? Entre "eh, j'ai fait des tests, et cela marche, mais pour les 99.999% des cas non testés, ben je ne sais pas trop" et "mon architecte, avec l'aide du mathématicien, ont démontré que le code marchera toujours", y'a une sacrée marge, non? Il a quand même une notion de garantie dans la démonstration (ou preuve) que je ne retrouve pas dans le test simple.
Citation :Pour mon code, ta preuve n'est pas recevablePourquoi? J'ai pas dit que this.x aurait la même valeur qu'après le premier "set()". En revanche, au vu du code, je peux faire l'hypothèse que this.x a la valeur assignée leur du dernier appel à set() ou la valeur null (c'est pas génial comme hypothèse et même complètement inutile, mais je peux la faire).
Pas faux, n'ayant pas donné de spécif, preuve ou test n'ont aucun sens. J'ai justement induis que plus() devait sommer deux nombres et renvoyer leur somme, j'ai fais exactement la même chose qu'un test qui induirait que la fonction marche.
Et tu te dis peut-être que la preuve mettrai des mois ou des années à se faire... C'est peut-être juste un manque de pratique
iffle: De toute façon, dans tous les cas, ma preuve une fois faite est terminée et enterrée, tandis qu'avec l'approche des tests, il faut de façon continue "surveiller" et corriger le système. Le test a une sorte d'approche "blacklist" là où la preuve est plus "whitelist".Après, ok, ce qui m'échappe peut être c'est l'approche "informatique technique", où un truc boiteux vaut mieux que prendre le temps de faire un truc robuste...
Belle trouvaille que ce lien, niahoo. D'ailleurs, sur des systèmes parallèles, vous vous fiez là encore à des simples "tests"?!
/PS
Citation :Mais quand les tests sont bien conçus, les satisfaire satisfait aussi le besoin.Ok. Tu me payes quoi si je te prouves que quelque soit les N tests que tu feras, si jamais l'élément testé accepte au moins N+1 état d'entrée, alors l'élément peut être buggé et le besoin insatisfait?