Je suis d'accord avec le principe de "valider une unité de code", ce n'est pas quelque chose que je remet en question.
Ce que je remet en question, c'est le fait de passer par des tests unitaires, qui ne vérifient qu'une seule et unique situation, pour en induire que toute la fonction marche. "Bien testé", ça veut dire quoi? En termes logiques, cela veut dire "valide pour toutes les entrées qu'elle pourra accepter", et les tests unitaires ne font pas cela, puisqu'ils ne testent qu'un lot précis d'entrées...
A mon sens, il vaut mieux faire la preuve "papier", à partir du code source de la fonction. Ainsi, on pourra dire "cette fonction marche pour toute entrée acceptable, en voici la preuve", et à partir de là on pourra l'utiliser. Mais dire "cette fonction passe mes tests unitaires donc elle marche", c'est péremptoire...
Pour la partie "preuve de fonctionnement, pas pour la documentation, le test unitaire me semble être totalement insipide et inutile, puisqu'on a besoin non pas d'un test, mais d'une preuve unitaire. Et le test unitaire tel que présenté ainsi me semble donc inutile dans le cadre de la preuve de fonctionnement d'un bout de code (ne serait-ce que le principe de "prouver de l'extérieur d'une classe que l'intérieur de cette classe marche" devrait choquer).
Ce que je remet en question, c'est le fait de passer par des tests unitaires, qui ne vérifient qu'une seule et unique situation, pour en induire que toute la fonction marche. "Bien testé", ça veut dire quoi? En termes logiques, cela veut dire "valide pour toutes les entrées qu'elle pourra accepter", et les tests unitaires ne font pas cela, puisqu'ils ne testent qu'un lot précis d'entrées...
A mon sens, il vaut mieux faire la preuve "papier", à partir du code source de la fonction. Ainsi, on pourra dire "cette fonction marche pour toute entrée acceptable, en voici la preuve", et à partir de là on pourra l'utiliser. Mais dire "cette fonction passe mes tests unitaires donc elle marche", c'est péremptoire...
Pour la partie "preuve de fonctionnement, pas pour la documentation, le test unitaire me semble être totalement insipide et inutile, puisqu'on a besoin non pas d'un test, mais d'une preuve unitaire. Et le test unitaire tel que présenté ainsi me semble donc inutile dans le cadre de la preuve de fonctionnement d'un bout de code (ne serait-ce que le principe de "prouver de l'extérieur d'une classe que l'intérieur de cette classe marche" devrait choquer).