TDD – Parte 2: 1, 2, 3… Testando

No último post eu dei uma breve introdução ao TDD. Muito breve, por sinal. Que só serviu mesmo para entendermos que é, acima de tudo, uma prática de design. Além de dar uma breve olhada em como fazer um teste.

Neste post, minha intenção é dar um pouco mais de sentido à prática do TDD fazendo alguns testes em cima de uma cesta de compras. Com isto, pretendo deixar um pouco mais claro a idéia de “Especificação Executável”.

Antes de começar, preciso ressaltar que muito do que será escrito aqui se baseia nas conclusões que eu mesmo cheguei a respeito do uso do TDD, e que podem ser equivocadas. Exatamente por isto, todo o feedback é bem-vindo. Minha vida é um constante processo de aprendizado.

Ok. Admito. O exeplo do último post foi muito tosco. Mas não é fácil bolar exemplos para posts. Ou você pensa em algo muito tosco ou acaba se envolvendo em algum exemplo que levaria 40 horas para desenvolver. E ninguém tem esse tempo hoje em dia. Talvez, você goste mais dos exemplos no blog do Vinícius Quaiato. Tem gente com mais talento que eu pra pensar em exemplos rápidos.

Neste post, eu tentei reformular um outro caso para colocar o TDD em prática. Se trata de uma cesta de compras simples. Então, vamos lá.

Comecei o projeto, como esperado, pela classe de testes:

Para executar os testes, precisa-se antes implementar as classes:

E aí rodamos os testes para conferir os vermelhos.

E, agora, vamos atrás das correções para conseguir o verde.

Talvez você esteja pensando em por que eu não fiz com que o Get do TotalAmount já não fizesse a soma dos itens. É necessário entender, ou, pelo menos, foi assim que eu entendi, que o vermelho é um passo importante no seu teste. Você precisa fazer com que ele nasça falhando. E um dos meios de fazer isso é não corrigir erros que você ainda vai testar.

Pode parecer bobeira para um exemplo desse. Mas nós nos damos com situações de softwares cujo os requisitos mudam o tempo todo, e seus testes precisam indicar o impacto exato de cada mudança no requisito.

Assim, podemos seguir adiante para o próximo teste:

Aqui ficou claro a forma do por que fiz o “Get” do TotalAmount ser falho.

Agora temos o verde. Mas o que acontece se rodarmos todos os testes? O teste anterior falha devido a um erro na implementação do código. Aqui temos uma chance de aplicar um refactoring.

TDD ganha ainda mais firmeza no sentido especificação executável, quando colocamos em mente de que realmente não estamos testando, estamos especificando. Veja este próximo teste:

Você notou que agora o item possui 2 unidades na propriedade Quantity?

Ele pega o programador no pulo. Pois um programador desavisado iria facilmente cair em uma situação simples dessa, um erro inesperado. Quando fazemos dos testes especificações, colocamos neles todas as variações possíveis. É claro que eu não preciso refazer o teste com mais ítems, já que este já foi feito.

Outro teste que casa com a definição de especificação executável:

O atributo ExpectedException na declaração do método de teste faz o teste significar algo como “Quero testar se uma exceção é lançada em tal situação.” Se a exceção não for lançada, então há um problema. Isto é muito bacana. Pois até mesmo as exceções fazem parte da especificação.

Para não parecer uma especificação tão incompleta, podemos acrescentar mais um testezinho…

Experimente especificar mais testes para esta solução, ou invente uma e pratique. Chega a ficar divertido depois que nos acostumamos.

Conclusão

Quanto mais incremento minha especificação, mais aumento a testabilidade do meu software. Com a ajuda do TDD, fica fácil saber se o software obedece a especificação: basta rodar os testes e esperar tudo verde.

No próximo post falaremos de uma abordagem do TDD que visualiza sua aplicação sob outra perspectiva: o Comportamento (BDD).

Stay Sharp.