Testes Automatizados

Se você estiver trabalhando com TDD então até onde entendo o ciclo de vida é:

• Teste (comece com testes simples)
• Desenvolva a classe e os métodos
• Refatore
  (Repita esse ciclo)

Se você estiver a fim de usar TDD sim, os testes devem ser feitos antes da implementação.
Você deve prover a classe que futuramente tera implementação e seus metodos e depois iniciar
com os testes. Veja você nao quebrou a regra primeiro ira escrever o teste depois a implementação.

Nao precisa de uma interface e sim de uma classe sem implementação ainda como eu ja disse logo acima…

Uhmn ? :roll: [ Pode explicar melhor? ]

Posts que fazem a gente pensar (tem de tudo um pouco, de uma garimpada):

Guilherme Chiapienski

http://gc.blog.br/2007/06/20/slides-da-palestra-sobre-tdd-no-riojug/

http://gc.blog.br/2007/06/08/como-produzir-software-coxa/

http://gc.blog.br/2007/05/31/testes-com-selenium-em-varios-browsers/

http://gc.blog.br/2007/05/30/qual-e-o-percentual-ideal-de-cobertura-de-testes/

http://gc.blog.br/2007/05/09/test-driven-development-in-a-nutshell/

Phillip Calçado:

http://blog.fragmental.com.br/2007/06/30/revisao-de-codigo-com-testes-unitarios/

http://blog.fragmental.com.br/2007/06/28/testando-constantemente/

Danilo Sato

http://www.dtsato.com/blog/default/Agile/?permalink=Qualidade-Just-in-Time.html&smm=y

http://www.dtsato.com/blog/default/Agile/XP/?permalink=Voce-automatiza-seus-testes-de-aceitacao.html&smm=y

http://www.dtsato.com/blog/default/Agile/?permalink=Chega-de-Processos.html&smm=y

http://www.dtsato.com/blog/default/Personal/?permalink=Multi-Tasking-e-Auto-Organizacao.html&smm=y

ASOBrasil:

Se você estiver trabalhando com TDD então até onde entendo o ciclo de vida é:

• Teste (começe com testes simples)
• Desenvolva a classe e os métodos
• Refatore
  (Repita esse ciclo)

Isso justamente porque uma das coisas que o TDD prega é que o seu design deve crescer aos poucos, de forma orgânica, se adaptando às suas necessidades.

Nao vai ser por falta de fontes que vc nao vai resolver seu problema. Aqui vai mais uma:

Test-Driven Development é criar um teste que identifica que uma situação não está de acordo com sua especificação (seu teste). Se você escreve um teste e ele não funciona como esperado é porque você precisa implementar algo.

Quando se escreve um teste e este não compila esse é a primeira coisa que está fora da especificação. Segundo a especificação representada por aquele teste deveria haver uma classe X com um método Y, se não possui o teste está quebrado. Testes quebrados devem ser corrigidos.

Faça um teste de cada vez, não vá escrevendo testes antes do código. Escreve umt este, faça ele passar, refatore. Escreva outro teste, faça ele passar, refatore. Escreva outro teste, faça ele passar, refatore. Escreva outro teste, faça ele passar, refatore. Escreva outro teste, faça ele passar, refatore…