Bon, j'aurai quand même aimé avoir un exemple plus codé mais soit.
Supposons, Roworll, que j'ai un bout de papier (ou autre système un peu plus évolué type documentation expliquant la preuve) qui prouve que, initialement, vehicle.destroy() marche. Si je fais une modification sur vehicle.destroy(), je dois effectivement refaire la preuve, ou m'assurer que la modification n'a pas altéré les hypothèses de la preuve. Si tel est le cas, la preuve est toujours valable et vehicle.destroy() marchera toujours aussi bien.
Si c'est "plus évolué que cela", alors les tests unitaires valident quoi? Ok, si le test unitaire foire, la classe foire, mais l'inverse est faux... Mon but n'est pas de prouver que ma classe foire, mais de prouver qu'elle marche. Prouver que 2+2 ne vaut pas 5 ne prouve pas que cela vaut 4 (encore moins 3).
En un sens, est-ce qu'il n'existerait pas une méthode qui permettrait de faire des tests type "fonctionnel" (aka, basé sur le test de la fonction et non basé sur le test de certaines valeurs)?
Parce qu'au fond, le test unitaire va à l'encontre de l'encapsulation: je veux tester de l'extérieur d'une classe que l'intérieur de la classe marche bien... C'est... paradoxal je trouve.
@Sephi
D'accord, en tant que documentation par l'exemple, pourquoi pas.
Mais pourquoi est-ce que cela permet de détecter les régression? D'accord, cela peut en détecter certaines, mais clairement pas toutes et donc on se retrouve avec un code "à moitié" validé. Pourquoi ce glissement depuis "documentation / pilotage projet" vers "preuve de fonctionnement"?
Citation :Mais avec une fonction qui mérite vraiment un test, tu peux prouver que ta fonction est correcte pour tous les cas si un ou plusieurs cas de base sont correctsD'accord, donc t'as quand même bien besoin d'une preuve, en plus des tests unitaires, qui dit "si tel et tel cas marchent, alors tous les cas marchent". Qu'est ce qui te prouve, en cas de modification, que la régression ne va pas porter sur cette preuve?
Supposons, Roworll, que j'ai un bout de papier (ou autre système un peu plus évolué type documentation expliquant la preuve) qui prouve que, initialement, vehicle.destroy() marche. Si je fais une modification sur vehicle.destroy(), je dois effectivement refaire la preuve, ou m'assurer que la modification n'a pas altéré les hypothèses de la preuve. Si tel est le cas, la preuve est toujours valable et vehicle.destroy() marchera toujours aussi bien.
Si c'est "plus évolué que cela", alors les tests unitaires valident quoi? Ok, si le test unitaire foire, la classe foire, mais l'inverse est faux... Mon but n'est pas de prouver que ma classe foire, mais de prouver qu'elle marche. Prouver que 2+2 ne vaut pas 5 ne prouve pas que cela vaut 4 (encore moins 3).
En un sens, est-ce qu'il n'existerait pas une méthode qui permettrait de faire des tests type "fonctionnel" (aka, basé sur le test de la fonction et non basé sur le test de certaines valeurs)?
Parce qu'au fond, le test unitaire va à l'encontre de l'encapsulation: je veux tester de l'extérieur d'une classe que l'intérieur de la classe marche bien... C'est... paradoxal je trouve.
@Sephi
D'accord, en tant que documentation par l'exemple, pourquoi pas.
Mais pourquoi est-ce que cela permet de détecter les régression? D'accord, cela peut en détecter certaines, mais clairement pas toutes et donc on se retrouve avec un code "à moitié" validé. Pourquoi ce glissement depuis "documentation / pilotage projet" vers "preuve de fonctionnement"?