Es común que aquellos que no tienen un conocimiento profundo de ambos temas tiendan a pensar que son enfoques intercambiables o incluso opuestos en el desarrollo de software.
Un interesante intercambio en el grupo de usuarios de Eiffel sobre el tema muestra una precisa distinción entre ambos que quería compartir.
Dice, Tomas Beale:
Dice, Tomas Beale:
One thing I mentioned some time ago on this topic is the broad misunderstanding of DbC by people who should know better. I was looking at Scala blogs and wiki pages written by its designers, and they said that DbC was not really needed since Scala had TDD. That betrays a poor understanding of both.Thinking about ways to explain the difference, I always understand the DbC pre- and post-condition specification for a routine F as a 'function' that maps a limited domain (the possible arguments + current object state) to a specific range (the answers, or behaviours in the case of a procedure) - it is therefore a mathematical requirement specification of the implementation of F (and it needs to be fully specificed to do this job properly - something we currently hardly ever do).On the other hand, TDD to be a specification of specific members of the input domain + required correspondents in the range. So DbC is about functions, and TDD is about probing these functions with test data. Defining DbC in terms of these 'functions' offers possibilities for machine-verifiable software, which I know ETH and many others are working hard on.But the outside world still doesn't seem to get this. And yet the original ideas come from Djikstra in the 60s!
Para profundizar un poco más otro usuario (Peter Gummer) recomienda el siguiente paper:
Para leer y reflexionar.
