Tecnologia

Desmistificando o TDD

Por: , setembro 26, 2013

Quando você pretende comprar um sapato novo, qual a primeira coisa que você faz? Normalmente as pessoas experimentam o sapato, vêm se é confortável, como é andar com ele, se combina com seu estilo, se te deixa mais alto, mais baixo… Tudo isso para que depois de algumas perguntas e especulações para si mesma ela opta por comprar ou não o sapato.

E com seu código, você também faz isso? Antes de utilizá-lo efetivamente, você faz perguntas para si mesmo se ele está bom, se passa no teste de “qualidade”, será fácil para posteriormente alguém utilizá-lo… Ou seja, você testa o seu código efetivamente?

Por que testar?

Temos hoje algumas práticas que podem te responder essas e outras perguntas, entre elas temos o TDD (test driven development) que irá te conduzir (como o próprio nome diz) a desenvolver código voltado a testes. Mas por que devemos desenvolver baseados em testes?

“If you don’t drive development with tests, what do you drive it with? Speculation? Specifications (ever notice that those two words come from the same root?” – Kent Beck – TDD by Example

Testar software muitas vezes não é uma tarefa fácil, muitos acreditam que escrever testes é uma tarefa demorada, que na maioria das vezes não lhe trará nenhum beneficio, outros acreditam que o custo benefício não vale a pena. Mas isso não é verdade! Escrever testes lhe garante segurança e comodidade para fazer qualquer alteração necessária no código, para que ao final da execução de seus testes, apresentará o resultado de que o código que você alterou mudou o comportamento de N métodos, que N funcionalidades irão quebrar , e tudo isso com um feedback rápido para que sua equipe tome alguma decisão para o próximo passo.

TDD, como funciona? Como usá-lo?

Com TDD você praticamente será obrigado a escrever testes para fazer uma nova funcionalidade. Ele funciona na forma de um ciclo, onde devemos:

                    

Fonte: http://ayagebeely.blogspot.com.br/

 

1- Escrever um teste, geralmente começando com uma barra vermelha nos resultados.

2 – Fazer os Teste passarem: escrever uma implementação dos métodos atribuindo-lhes o comportamento desejado, até que se tenham todos os testes passando. Em um primeiro momento você não deve se preocupar muito com alguns smells que podem aparecer, pois até que os testes passem você não tem a garantia de que aquele teste e aquele código feito estão se comportando da maneira esperada, tendo isso você deve, sem dúvida, partir para o próximo passo (o mais importante, independente da prática que você vai utilizar para desenvolver).

3 – Refatorar – talvez o passo mais importante do TDD (não necessariamente especifico do TDD, mas algo que todo desenvolvedor deve fazer após escrever algumas linhas de código). Com uso de TDD, a refatoraçao se torna muito mais fácil e segura, pois você garante que as alterações que você irá fazer no código não irão influenciar no comportamento do código já existente (o código que você acabou de escreveu no passo 1). Nesta parte você irá remover os smells gerados enquanto você fazia o primeiro passo, muito provavelmente alguns outros smells que também devem ser eliminados.

Trabalhando dessa forma, no final você terá um código testado, muito provavelmente você terá eliminado alguns smells no código, além do que, em um futuro próximo, se for preciso fazer alguma alteração no código, você poderá ter mais confiança para fazer está alteração.

Garantia de qualidade no projeto?

Mas fazendo esses passos, eu sempre vou garantir qualidade do meu código? Se for, então é só minha equipe começar a usar TDD, que no final teremos um código “5 estrelas”, sem bugs, fácil de dar manutenção, com design simples… ? Na verdade, não. O uso do TDD só garante que você terá testes para o código que você produz, usando TDD seu código e design, não ficaram bons em um passe de mágica, você não irá criar classes menos acopladas com uso de TDD. Tudo isso faz parte da visão que o programador tem em saber reconhecer smells e boas práticas, com TDD ao escrever testes para novas classes e métodos você poderá ter um feedback de smells logo no começo do desenvolvimento, assim você poderá fazer ou não a refatoração necessária  Esses são um dos argumentos que programadores mais experientes acreditam que TDD não deve ser considerado como uma prática obrigatória no desenvolvimento.

Quando usar ou não TDD

Na verdade o TDD pode ser usado para qualquer situação em que você possa escrever um teste. Talvez a pergunta certa seja quando não testar? Muitas pessoas defendem que tudo pode ser testado, mas será que tudo deve ser testado? Testar métodos que você tem certeza do que está sendo feito, testar métodos de alguma API que você está utilizando, são exemplos em que não devemos nos preocupar em testar, ou seja, você deve testar código que sua equipe escreve(que dá manutenção) e não se preocupar com código de terceiros ou métodos que tenham uma  implementação(get/setters por exemplo) óbvia.

Você deve escrever testes ao ponto de trazer o minimo de confiança sobre a regra de negócio implementada, para que você tenha certeza do que acontece hoje, se houver alguma mudança futura, seu teste poderá acusar essa alteração e assim você terá provavelmente uma barra vermelha nos testes.

Levando em conta tudo isso como eu posso trabalhar com TDD? Sempre devo trabalhar com TDD? Não existe quando, nem como trabalhar com TDD, TDD é uma prática onde as pessoas optam ou não por utilizar em determinadas situações.

Por exemplo, se você está em uma atividade que calcula o total de uma conta bancaria e para conseguir checar se está realizando o cálculo correto, você terá que fazer 5 operações diferentes, executar um job, fazer a validação das operações da conta para que no final você entre na tela e consiga verificar o total da conta bancaria e descobrir que esqueceu de somar um valor e terá que realizar todos os fluxos novamente para poder visualizar se o cálculo está correto, para essa situação é muito melhor você trabalhar com TDD e já ter o seu método de calcular total já testado e demorar 2s para testar, do que fazer todos os fluxos toda vez que você tiver que fazer uma alteração no código, além disso é bom ter este tipo de teste para garantir que esses fluxos se um dia forem alterados, no final o calculo da conta ainda estará funcionando e validado com os testes, ou irá indicar que o alguma coisa foi alterada e o teste não está passando mais.

Uma outra situação seria quando você não tem o conhecimento de tudo o que poderá ser afetado com as alterações que você pretende fazer, logo, você terá que ter consiência de que se você for alterar alguma coisa e ainda não existir nenhum teste para esse fluxo, antes de escrever qualquer linha de código é bom que você escrever um teste para ter certeza de que o fluxo atual se comporta de uma maneira X, e assim que você começar fazer as alterações ele passara a se comportar da maneira esperada com as alterações realizadas.

TDD x Cobertura de testes

Então quer dizer que fazendo TDD eu vou ter praticamente tudo testado, logo eu vou chegar a uma cobertura próxima dos 100%, é isso mesmo? Além de me ajudar com diversas coisas, ele também vai me ajudar a ter uma cobertura de testes alta,? TDD é a salvação ? TDD pode sim ajudar a aumentar a cobertura de testes de um projeto, porém não é uma verdade verdadeira – “Mas como assim?”  – Se você hoje, independentemente se usa ou não TDD, já escreve testes no decorrer do desenvolvimento, com TDD você não verá nenhuma melhora significativa de cobertura, porém se você não tem o hábito de escrever testes o TDD irá agir de uma maneira implicita, fazendo com que você seja obrigado a escrever testes, logo sua cobertura de testes irá melhorar. Um ponto que eu acredito fielmente é que após usar/aprender e ver os beneficios no desenvolvimento com TDD, você como programador irá sentir a necessidade de escrever testes e fará isso não por obrigação(como é a proposta do TDD), mas por desejo e sentimento de segurança.

Mas lembre-se que escrever testes para get/setters, métodos sem lógica em si, é uma ilusão de que você está escrevendo algum testes, se você faz isso, você só está criando a ilusão de que sua cobertura de testes está “boa”. É muito mais válido você testar coisas que sempre estão mudando e que tendem a “quebrar” no decorrer do desenvolvimento. Resumindo, teste o que é para ser testado, se você tem certeza do que está acontecendo, como um get/set, não perca seu tempo escrevendo esses tipos de testes, escreva testes para métodos que teem regra de negócio associada, métodos que tendem a quebrar com o desenvolvimento do seu projeto.

O TDD pode lhe trazer muitos beneficios, porém esses benefícios são exclusivamente dependentes da atitude do programador em identificálos, com ou sem a prática do TDD. Uma analogia que pode ser usada para explicar o por que o TDD é apenas mais uma prática, é relacionar a programação com a saúde de um indivíduo e a prática de algum esporta/atividade física para o TDD, ou seja, fazer atividade física pode ajudar a ter uma boa saúde, mas ainda assim existem pessoas que fazem alguma atividade física e teem problema algum de saúde, da mesma forma que existem pessoas que não praticam nenhuma atividade física e tem uma boa saúde.

 

  • Receba nosso conteúdo em primeira mão.