Testes automatizados, test first e TDD. Quando onde e porque?

[rmendes08]

Olá a todos, a discussão que quero levantar é a seguinte:

1 - diferenciar os termos: testes automatizados, test first e TDD, apesar de relacionados, são coisas diferentes. Gostaria de saber dos colegas o que cada um entende por estes termos.

2 - aplicabilidade: sabemos que podemos automatizar testes em diferentes camadas do nosso software, desde a persistência até a interface. O que eu gostaria de discutir nesse sentido , e saber da experiência dos colegas é quando vocês acham mais adequado usar um ou outro. Por exemplo, é possível projetar uma interface com TDD ? e classes de acessam o banco de dados ? é viável escrever um teste de integração antes da integração ?

[javaflex]

Só posso falar um pouco sobre os testes funcionais pois os outros não tem necessidade pra mim.

O funcional logicamente é feito depois de desenvolver a funcionalidade e atua no nível mais alto, o real, ou seja, automatizando o usuário usando à vera, utilizando Selenium por exemplo. Muitas vezes não adianta fazer um monte de testes de métodos num teste de integração, se por algum motivo quebrar algum javascript ou outra coisa qualquer no meio do caminho entre as ações do usuário e o retorno visual esperado.

[s4nchez]

[quote=rmendes08]Olá a todos, a discussão que quero levantar é a seguinte:

1 - diferenciar os termos: testes automatizados, test first e TDD, apesar de relacionados, são coisas diferentes. Gostaria de saber dos colegas o que cada um entende por estes termos.
[/quote]

Ao meu ver estas tecnicas estao contidas uma nas outras da seguinte forma:

[TDD [test first [automated test]]]

• automated tests: uso de qualquer ferramenta que substitua testes manuais (jUnit, Selenium etc)
• test first: criacao de qualquer teste automatizado antes do codigo de producao
• TDD: ciclo “teste automatizado -> codigo producao -> refactoring” + baby steps

O que eu gostaria de discutir nesse sentido , e saber da experiência dos colegas é quando vocês acham mais adequado usar um ou outro.

Melhor deixar outra pessoa responder:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order

via http://stackoverflow.com/a/153565

Por exemplo, é possível projetar uma interface com TDD ? e classes de acessam o banco de dados ? é viável escrever um teste de integração antes da integração ?

A resposta para todas eh sim. Por outro lado, principalmente para quem esta comecando, eh muito facil acabar tendo mais problema do que beneficios tentando aplicar a tecnica.