TDD é uma técnica bastante utilizada hoje por diversos times. Os benefícios de tal abordagem já estão mais do que comprovados em diversas literaturas como neste artigo publicado na InfoQ. Porém essa forma de iniciar sua funcionalidade pelo teste deve começar por qual parte do nosso projeto? Se estivermos utilizando uma abordagem MVC devemos começar pelos controladores, pela tela ou pelo modelo?
Em um recente discussão no mais novo fórum de arquitetura do Brasil, o Tectura, André Silva iniciou a seguinte discussão: "Por onde começar a codificar o Teste" com a pergunta:
Bom seguindo o conceito de TDD, devemos começar sempre pelo teste. No caso estou criando uma funcionalidade nova, por exemplo: cadastro de aluno. Aqui surge uma dúvida que eu sempre tive: por onde começamos?
Bom, geralmente eu começo pela entidade. [...] Gostaria de saber se está forma que eu faço é correta? Tem outra forma de fazer?[...]Então agora com a entidade “existindo” eu consigo criar os testes das outras camadas (persitência, controle, etc..). Ou é possível criar esses testes (persistência, controle, etc) sem a entidade existir?
Igo Coelho sugeriu utilizar, em conjunto, uma outra abordagem utilizando o Behavior Driven Development (BDD).
Esse geralmente é o caminho seguido por parecer mais natural. Tentando ajudar mais sem querer te deixar com mais dúvida, já pensou em usar BDD? Conhece o JBehave? Quando você começar a pensar nos testes partindo do entendimento de qual funcionalidade você deseja desenvolver a coisa fica mais natural. Daí você parte tanto para teste de aceitação quanto para o de unidade juntando BDD com TDD.
Concordando parcialmente, Luiz Corte disse que é possível seguir essa linha de raciocinio (pensar nos testes partindo de qual funcionalidade você deseja desenvolver - apenas com a utilização do BDD, ele diz:
Realmente começar pensando na funcionalidade que você quer implementar ajuda bastante. Mas não precisa usar BDD para seguir essa linha; dá pra fazer TDD assim.
Meu jeito de começar pensando na funcionalidade é começar com os testes de controladores, afinal são eles que vão “orquestrar” seu sistema e delegar as coisas para os caras que realmente fazem (isso se você estiver usando MVC). Nos testes desse cara, coloca mock em tudo quanto é dependência que você tiver, e aí você já vai definindo a interface que suas dependências vão ter que seguir.
Guilherme Silveira mostra uma outra forma de iniciar seus testes começando pelo teste end-to-end (testes que simulam a utilização do usuário final).
Mais um caso diferente, nos sistemas que temos teste de integração, costumamos começar pelo teste de end-to-end que nos diz o caminho geral, fazemos ele compilar (quando a linguagem for compilável), implementamos o teste unitário e o código. Repetimos o teste unitário e código até o teste end-to-end passar.
Com isso temos o end-to-end que nos deu o behavior e o unitário que nos deu os detalhes finos.
Durante a discussão foi possível observar que as opiniões são variadas e não é possível dizer que uma abordagem é de fato a melhor de todas, isso depende do que o desenvolvedor prefere e a forma que mais ajudará no seu raciocínio.
E você leitor prefere começar seus testes por qual parte? Qual a importância que você vê na escolha dela? Começar pelo lugar errado pode ou não gerar problemas no futuro?