Jefferson Girão :: Tech

Pesquisando sobre Acceptance Test Driven Development esbarrei nessa apresentação compartilhada por Naresh Jain em meados de 2008 com foco no Fitnesse. Achei muito interessante o alerta que ele dá sobre como não se fazer testes de aceitação:

Desenvolvedores escrevendo testes de aceitação por eles mesmos, para eles mesmos

Testes de aceitação são para colaboração e comunicação. Usá-los apenas para testes é subutilizar o potencial. Todos os interessados na funcionalidade devem estar envolvidos na construção dos testes de aceitação.

Testes de aceitação escritos em nível unitário

Testes unitários são específicos da implementação enquanto que testes de aceitação não são. Testes de aceitação expressam objetivos de negócios, enquanto que testes unitários expressam, tecnicamente, objetivos de dada implementação.

Escrever os testes após o código estar pronto

Escrever testes de aceitação após o código estar escrito não traz benefícios suficientes comparado a escrevê-los antes e deixá-los guiar o desenvolvimento.

Esconder dados de testes em fixtures

Esconder dados que afetam o comportamento testado é uma má idéia. Estamos falando sobre comunicação: certifique-se que seus testes comunicam o objetivo ( dados de teste fazem parte do teste ).

Testes dependentes de detalhes de implementação e estruturas dos dados

Testes de aceitação precisam ser independentes de plataforma, tecnologia e implementação. Se daqui a uns anos você decidir portar a aplicação para uma nova tecnologia ou arquitetura, com poucas alterações em fixtures deve ser possível rodar os testes de aceitação contra o novo sistema.