TDD 

Desenvolvimento Orientado
por Testes

Yasmin Castro e Leticia Farias

O QUE É?

TDD é o Desenvolvimento Orientado por Testes (Test Driven Development). É

onde desenvolvemos o nosso software baseado em testes que são escritos antes
do nosso código de produção!

Basicamente o TDD se baseia em pequenos ciclos de repetições, onde para cada

funcionalidade do sistema um teste é criado antes. Este novo teste criado
inicialmente falha, já que ainda não temos a implementação da funcionalidade
em questão e, em seguida, implementamos a funcionalidade para fazer o teste
passar! Simples assim!
 Ciclo de Desenvolvimento
Red,Green, Refactor. Ou seja:

Escrevemos um Teste que inicialmente não passa (Red)

Adicionamos uma nova funcionalidade do sistema(Yellow)
Fazemos o Teste passar (Green)
Refatoramos o código da nova funcionalidade (Refactoring)
Escrevemos o próximo Teste.

Nós temos, neste tipo de estratégia, um feedback rápido sobre a

nova funcionalidade e sobre uma possível quebra de outra
funcionalidade do sistema. Assim tempos muito mais segurança
para as refatorações e muito mais segurança na adição de novas
funcionalidades.
 Motivos para o uso
• Temos diversos ganhos com esta estratégia e vou citar alguns:
 Feedback rápido sobre a nova funcionalidade e sobre as outras
funcionalidades existentes no sistema Código mais limpo, já que
escrevemos códigos simples para o teste passar.
 Segurança no Refactoring pois podemos ver o que estamos ou não
afetando.
 Segurança na correção de bugs.
 Maior produtividade já que o desenvolvedor encontra menos bugs e
não desperdiça tempo com depuradores.
 Código da aplicação mais flexível, já que para escrever testes temos
que separar em pequenos "pedaços" o nosso código, para que sejam
testáveis, ou seja, nosso código estará menos acoplado.
MITO

Muitos ainda não gostam da ideia do TDD pelo fato de termos mais código
a ser desenvolvido, acarretando maior tempo no desenvolvimento de uma
funcionalidade. Mas isto está errado. Com toda certeza você desenvolvedor
já corrigiu um bug no sistema, mas criou outros dois no lugar. Isto acontece
com muita frequência e muitas das empresas ainda pagam os
desenvolvedores somente para corrigirem bugs e até reescreverem sistemas
cuja manutenção é terrível, traumática e sangrenta!
Reforçando os motivos
A médio prazo (e dependendo do sistema a curto prazo) este tempo de
desenvolvimento com TDD é menor que o tempo de manutenção
corrigindo bugs e mesmo para adicionar funcionalidades novas. Isto
devido, resumidamente, a:
Confiança do desenvolvedor na correção de bugs, pois qualquer passo
errado será mostrado pelos testes
Tempo de desenvolvimento menor na adição de funcionalidades, já
que o sistema é mais flexível e o código mais limpo
Menor tempo do desenvolvedor ao corrigir bugs após aquelas
incessantes brigas com o pessoal de qualidade depois da famosa frase
"Mas na minha máquina funciona!"
Possibilidade de Integração Contínua, com builds automáticos e
feedbacks rápidos de problemas.
Novo Teste
• Este primeiro passo é o pilar do TDD (não brinca!). Temos uma nova
funcionalidade do sistema e fazemos o processo inverso ao
tradicional: Testamos e Codificamos e não Codificamos e Testamos.
No primeiro momento isto parece estranho, esquisito ou feio, mas
não é. O fato de termos um teste primeiro que o código garante que
daremos passos simples para a codificação da funcionalidade, afim
de fazer o teste passar, ou seja, seremos "obrigados" a escrever uma
implementação simples para que o teste passe.
• No começo esta forma não é muito intuitiva e o gráfico de
aprendizagem não é lá um dos melhores, mas com o tempo e
aperfeiçoamento da técnica, esta será a forma mais intuitiva e segura
de desenvolver que você encontrará.
Teste Falhando
Neste momento, acabamos de escrever o teste e não temos a
implementação. Óbvio que o teste falhará, pois ele espera uma resposta
que ainda não temos implementada em lugar algum. Com um Teste
falhando na nossa frente, temos um único objetivo na vidaFazê-lo passar!
Passamos para a próxima fase.

Nova funcionalidade
Já ouviu falar no KISS? "Keep It Simple, Stupid", ou seja, devemos
escrever o nosso código da forma mais simples possível. Código limpo,
simples e funcional! Esta é a ideia. Assim, neste momento vamos esquecer
as Boas práticas, a Inversão de Controle, os Patterns, etc e vamos codificar a
nossa nova funcionalidade da forma mais simples possível para fazer o
nosso Teste passar. Neste momento estamos simplesmente escrevendo
alguma funcionalidade que faça o teste passar (sem quebrar outros testes) e
também teremos segurança na Refatoração deste mesmo código daqui a
alguns minutos. Vale lembrar também daquela sequência ótima de
desenvolvimento que devemos ter na cabeça: Código que funciona ->
Código simples e limpo -> Código rápido.
Refatoração
Neste momento é que vamos analisar melhor aquele código que fizemos
simplesmente para o nosso Teste passar. É neste momento que retiramos
duplicidade, renomeamos variáveis, extraímos métodos, extraímos
Classes, extraímos Interfaces, usamos algum padrão conhecido, etc. É
neste momento que podemos deixar o nosso código simples e claro e o
melhor de tudo: Funcional!
Temos um teste agora que indicará qualquer passo errado que podemos
dar ao melhorar o nosso código. E não somente este código que
acabamos de escrever. Após algum tempo com TDD, será criada uma
Suite de Testes, onde poderemos refatorar sem a preocupação de atingir
negativamente algum código já existente, pois já teremos
Testes indicando qualquer falha.
Já ouviu falar no SRP? "Single Responsibility Principle". Este princípio
nos diz que devemos ter somente um motivo para modificar uma classe.
Ou seja, ele fala sobre termos uma classe com somente uma
responsabilidade. Por que estou lembrando disso? Por que o TDD nos
"força" a termos classes seguindo esta regra, pois facilita os Testes. Não
podemos refatorar um trecho de código e quebrar vários Testes.
Mudanças seguras no
código
Muitos desenvolvedores ainda escrevem código
pensando nas modificações no futuro que este código
poderia ter e acaba escrevendo um código com
Factory, Singleton, Template Method, Bridge, Strategy
e todos os amigos do GoF. Este pensamento, apesar de
parecer seguro, contraria os princípios da Metodologia
Ágil.
Claro que o software sempre sofrerá mudanças e a
nossa preocupação de hoje é: Prever/Escrever um
código/design para modificar no futuro quando
precisarmos.
Mas deveria ser, escrever um código simples e claro,
que seja fácil modificar e seguro.
• Kent Beck, no seu livro também comenta sobre perdermos muito tempo imaginando um
Design que seja perfeito para aplicação e acabamos escrevendo um código que na maioria
das vezes não era necessário. Com TDD realmente abandonamos este pensamento,
justamente por queremos que o Teste passe logo, ou seja, escrevemos o nosso código da
forma mais simples possível.
• Como conseguimos um código simples? - Fazendo um Teste passar
• Como conseguimos um código claro? - Refatorando o código após ele passar
• Como conseguimos um código seguro? - Com Testes
Documentação para o limbo?
Aquela documentação no papel, em uma wiki, em um doc,
etc é desatualizada pois é muito custoso atualizá-la a cada
Refatoração/Mudança de código. A melhor documentação e
mais atualizada possível é a Suíte de Testes pois ela mostra
de forma simples como está funcionando o sistema naquele
exato momento. Se você percorrer os testes você entenderá
o que o sistema realiza.
O Desenvolvimento Orientado a Testes
realmente é mais produtivo?

● No Desenvolvimento Orientado a Testes, a entrega de uma funcionalidade pode ficar

comprometida de início. No entanto, a sua manutenção ao longo prazo será muito bem
recebida pela equipe, pois a partir dos testes conseguimos controlar exatamente o que está
sendo adicionado ou modificado.
● Muitas pessoas questionam a produtividade do desenvolvimento orientado a testes, isso
porque sempre que se pensa em adicionar uma nova funcionalidade na aplicação, também
se pensa muito na sua implementação e, consequentemente, nos seus testes.
● Porém, esse estudo realizado em 2015 com 25 participantes do Brasil mostra que o TDD
ajuda a pessoa desenvolvedora a pensar mais na funcionalidade que está sendo
desenvolvida, bem como na sua constante refatoração de código. Isso faz com que o 
código seja mais limpo e que também exista o feedback visual de quais linhas já foram
testadas ou não.
 Por que é tão difícil aplicar o TDD?
O desenvolvimento orientado a testes não é uma tarefa fácil porque:
Você deve entender muito bem a estrutura do que está criando para se previnir de possíveis
problemas.
O TDD não é uma prática usual para pessoas iniciantes, pois, para ser aplicado em um
projeto, leva tempo e muita prática.
Às vezes não temos tempo hábil para implementar, ou seja, estamos em uma equipe de
desenvolvimento e precisamos entregar a funcionalidade o quanto antes.
Infelizmente, essa é uma prática muito comum no mundo do desenvolvimento de 
software e acaba diminuindo a qualidade do código a longo prazo.
 Referências bibliográficas

 https://blog.engdb.com.br/driven-development/

 https://www.devmedia.com.br/test-driven-development-tdd-simples-e-pratico/18533

Vídeo Explicativo