But: program testing can be a very effective way to show the presence of bugs,
but is hopelessly inadequate for showing their absence. The only effective way
to raise the confidence level of a program significantly is to give a convincing
proof of its correctness. But one should not first make the program and then
prove its correctness, because then the requirement of providing the proof would
only increase the poor programmer’s burden. On the contrary: the programmer
should let correctness proof and program grow hand in hand.
On est pas loin du concept de TDD...
Mise à jour (4 février 2014)
Je viens de lire ceci dans un article sur le TDD :
An early reference to the use of TDD is the NASA Project Mercury in the 1960's (Larman and
Basili 2003). Je ne suis pas allé vérifier. Je suis quand même conscient que l'état d'esprit à l'époque était tellement différente que ça n'a probablement rien à voir mais je trouvais ça intéressant de le mentionner.
On est pas loin du concept de TDD...
Mise à jour (4 février 2014)
Je viens de lire ceci dans un article sur le TDD :
An early reference to the use of TDD is the NASA Project Mercury in the 1960's (Larman and
Basili 2003). Je ne suis pas allé vérifier. Je suis quand même conscient que l'état d'esprit à l'époque était tellement différente que ça n'a probablement rien à voir mais je trouvais ça intéressant de le mentionner.
2 commentaires:
Sauf que ce que Dijskstra avait à l'esprit quand il parlait de "correctness proof" était très (!) différent des tests unitaires, aussi sophistiqués soit-il. Dijkstra était un "pur et dur" formé aux mathématiques, et quand il parlait de "preuve", il voulait dire une preuve formelle et logique, basée sur des règles strictes de raisonnement.
Guy T.
Ah ! Merci pour ton commentaire éclairant.
Publier un commentaire