terça-feira, janeiro 11, 2005
Assertion Driven Development
Um tempo atrás, na lista do Test-Driven Development do Yahoo, surgiu um cara que propôs trocar o nome de TDD para ADD (Assertion-Driven Development). Eu até postei um comentário sobre isso.
Mas aí a discussão continuou, cada um propôs uma coisa, e ninguém modificou nada.
Esses dias atrás senti na pele o problema de colocar a palavra test num método de desenvolvimento. Está tão arraigado na cabeça das pessoas que teste é coisa pra se fazer no final do processo e que é responsabilidade da equipe de controle de qualidade, que eles param de te ouvir assim que vc menciona a palavra test.
Acho que é impossível mudar a mente das pessoas num curto espaço de tempo, e é desperdício de fôlego ficar explicando que vc chama de teste uma coisa que não é bem um teste do jeito que o cara conhece. Daí, ao invés de mudar o mundo, acho melhor mudar minha abordagem.
Pra mim tá decidido, nunca mais apresento TDD pra alguém como Test-Drive Development, pra mim agora é Assertion-Driven Development e ponto. Além do que, "ADD" é uma sigla muito mais comercial do que TDD.
Assinar:
Postar comentários (Atom)
Uma coisa que vale agregar é que para o desenvolvimento em ambiente JAVA, a SUN associou "assert" como modo de testes de suas classes.
ResponderExcluirAssim por definição da SUN, você pode fazer seus "asserts" dentro do sistema e não teste...
Ai também concordo que deve ser considerado com Assert Driven Development, pelo menos pela lógica aplicada dentro dos testes...
Bem, as asserções do Java foram inicialmente pensadas para DbC (Design by Contract) ou coisa parecida. Mas acho que a idéia na essência é a mesma, garantir que o código funciona por meio de asserções.
ResponderExcluirA diferença é que no ADD (já falei que não vou usar mais TDD) os testes são exemplos de uso E contratos.
Mas concordo contigo, já tem um esquema no Java para isso, o que torna o termo ainda mais familiar, só espero que não confundam as coisas.