Donc, en pratique, tu sais qu'ils ne le seront pas
Et en pratique, les spécifs changent.
Oui et non, en fait il faut rapprocher la programmation contractuelle à un cycle de maintenance (ou comme XProgramming) :
Tu fait tes specifs (contrats + tests) -> tu codes -> tu lances tes tests -> tu peux avoir des erreurs de violation de contrat (code faux ou contrat faux), dans ce cas tu modifie tes contrats/codes ou alors t'obtiens pas le résultat attendu (normalement détecté par une postcondition), donc tu modifie tes spécifs (donc tes contrats et ton code) et tu cycles jusqu'à avoir un niveau de confiance assez fort.
En gros ce sont des cycles très courts basés sur 3 points : Specification->Tests->Implémentation.
En plus tu peux générer des mutants (insertion d'erreur dans une classe) pour vérifier que tes contrats détectent bien les erreurs générées dans ces mutants.
[^] # Re: OCM 2002
Posté par pifou . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 4.
Et en pratique, les spécifs changent.
Oui et non, en fait il faut rapprocher la programmation contractuelle à un cycle de maintenance (ou comme XProgramming) :
Tu fait tes specifs (contrats + tests) -> tu codes -> tu lances tes tests -> tu peux avoir des erreurs de violation de contrat (code faux ou contrat faux), dans ce cas tu modifie tes contrats/codes ou alors t'obtiens pas le résultat attendu (normalement détecté par une postcondition), donc tu modifie tes spécifs (donc tes contrats et ton code) et tu cycles jusqu'à avoir un niveau de confiance assez fort.
En gros ce sont des cycles très courts basés sur 3 points : Specification->Tests->Implémentation.
En plus tu peux générer des mutants (insertion d'erreur dans une classe) pour vérifier que tes contrats détectent bien les erreurs générées dans ces mutants.