CENTRO UNIVERSITÁRIO UNA

TDD-Test Driven Development

Desenvolvimento guiado por testes

Pós-graduação em Engenharia de Software Centrada em Métodos Ágeis

TIME CAVE!RA

Bruno Eustáquio Andrade

Juliana Villas Bôas Fonseca
Marcelo Nascimento
Thiago Funghi
Thiago Ribeiro

Março/2011
 TDD – Test Driven Development – Desenvolvimento guiado por testes

Sumário

1. Introdução .................................................................................................................................................. 3
1.1. Origem ................................................................................................................................................. 3
1.2. Motivação ........................................................................................................................................... 3
2. Funcionamento .......................................................................................................................................... 3
3. Princípios de desenvolvimento................................................................................................................. 5
3.1. KISS - Keep It Simple, Stupid............................................................................................................... 5
3.2. YAGNI - You Ain’t Gonna Need It ....................................................................................................... 5
3.3. Fake it, till you make it ....................................................................................................................... 5
3.4. ATDD - Acceptance TDD ...................................................................................................................... 6
3.5. DRY - Don´t repeat yourself ou DIE - Duplicate is Evil ...................................................................... 6
4. Cenários ...................................................................................................................................................... 6
4.1. TDD desde o início .............................................................................................................................. 7
4.2. TDD na correção de bugs .................................................................................................................... 7
4.3. TDD em código legado ........................................................................................................................ 8
5. Integração do TDD ao Scrum .................................................................................................................. 10
6. Confusões com TDD ................................................................................................................................. 11
7. Cinco desculpas para não usar TDD ....................................................................................................... 12
8. Vantagens Desvantagens ......................................................................................................................... 13
9. Conclusão.................................................................................................................................................. 13
10. Bibliografia ................................................................................................................................................ 14

2
 TDD – Test Driven Development – Desenvolvimento guiado por testes

1. Introdução
TDD é um acróstico em inglês de Test Driven Development, traduzindo Desenvolvimento Dirigido a
Testes. TDD é uma técnica (englobada pelo XP (eXtreme Programming)) que contempla o desenvolvimento
a partir de testes. O programador escreve um teste inicialmente que será executado e falhará, após isso será
implementado código para fazer o teste ser validado e um novo teste falho será escrito e assim
sucessivamente…

1.1. Origem

Criado por Kent Beck e David Astels em 2003, o TDD é derivado do método Extreme Programming
(XP) e do Manifesto Ágil

1.2. Motivação

O que levou a criação do TDD:

• Implementar boas práticas de programação
• Antes de o código estar escrito, é preciso que as classes sejam realmente necessárias.
• TDD ajuda os desenvolvedores a focar na funcionalidade das aplicações e a disponibilidade
de testes antes do desenvolvimento e permite um rápido feedback.

2. Funcionamento
Os testes deverão ser escritos antes da implementação do código. Dessa forma, o desenvolvedor
recebe um retorno rápido do código testado posteriormente. O nível de stress do desenvolvedor aumenta
durante o processo de desenvolvimento do software. Com isto, os testes tendem a ser deixados para o final,
fazendo com que a quantidade de testes seja reduzida, reduzindo assim consequentemente a qualidade do
sistema.

Os dados utilizados nos testes devem cobrir todas as alternativas possíveis, ou seja, se o sistema
possui múltiplas entradas, um teste bem realizado deverá contemplá-las. Os dados incluídos nos testes
devem ter uma relação aparente entre entrada e saída. Os testes podem servir também como
documentação para que outro desenvolvedor possa, no futuro, entender e, se necessário, dar manutenção
no código.

Antes da codificação, deve ser escrita uma lista de testes, contemplando todos aqueles que o
desenvolvedor julga necessário para fazer a cobertura das possibilidades de entrada e saída. A lista será o
planejamento de cada requisito. Feito isto, ao começar a codificação, ele terá um guia para que não se
esqueça de nenhum teste, tornando o sistema mais robusto.

Após a especificação dos casos de testes, divididos

em pequenas porções de funcionalidades, os testes deverão
ser escritos, começando pela regra que o desenvolvedor
julgue mais simples. Inicialmente o teste deve falhar, para
que o chamado “mantra” do TDD seja obedecido. Este
mantra pode ser visto na figura ao lado.

3
 TDD – Test Driven Development – Desenvolvimento guiado por testes

Como foi citado anteriormente, a implementação do teste vem antes da implementação código,
permitindo o planejamento do design das classes, como serão as chamadas dos métodos e seu
funcionamento. Dentro da classe de testes, o método que irá testar o item eleito como o mais simples da
lista deverá ser criado, juntamente da assertiva que define onde o teste deverá chegar. É ela que garante
que o código está funcionando. O código não deve compilar, pois não foram criados a classe e o método
testado.

A criação do teste antes do código permite ao desenvolvedor enxergar pela ótica de quem utiliza a
classe e não pela ótica de quem esta criando, possibilitando a averiguação da facilidade de utilização,
entendimento e simplicidade. Toda esta visão, garantida antes da implementação, torna a sua alteração
“sem custos”, ou seja, como o código não foi implementado, a sua alteração não terá impacto algum,
diferentemente se esta visão seja apresentada apenas ao longo do projeto.

O segundo passo consiste em chegar mais rapidamente ao sucesso do teste, ou seja, implementar o
código que retorna como resultado na classe de testes o marco verde do “mantra”. Deve ser implementado
somente o necessário para que o sucesso seja alcançado, a melhoria do código se dá apenas na refatoração,
quando já está garantido o seu funcionamento.

É importante que os passos sejam curtos e, quando necessário, utilizar os chamados “Baby Steps”,
que fazem parte conceito de TDD. Implementar a aplicação pouco a pouco, recebendo o rápido feedback
dos resultados dos testes de pequenas porções do código, além de garantir o funcionamento de todo o
código, evita-se a criação de códigos complexos sem que haja necessidade. Para códigos onde o
desenvolvedor se sente seguro em implementar, os passos podem ser maiores, mas como afirma Kent, é
sempre bom saber que é possível a realização em passos menores.

Outra prática importante no TDD é a simulação do código antes da sua construção. A simulação faz
com que o desenvolvedor aprenda e planeje melhor o seu código. Ainda seguindo com as boas práticas,
mesmo que o desenvolvedor saiba que o resultado do teste não será o sucesso, o teste deve ser executado,
mantendo sempre a ordem de execução do “mantra” do TDD.

Continuando a implementação dos testes, após o sinal verde do teste executado, o código deve ser
refatorado, melhorando a implementação. Após refatorar, o teste deverá ser executado até que o sinal
verde apareça. Este processo deve ser repetido até que todas as regras definidas sejam atendidas,
resultando em um código simples e totalmente aderente aos requisitos. A refatoração deverá ocorrer
quantas vezes o desenvolvedor julgar necessária.

Caso sejam encontradas regras que necessitem da criação de testes distintos com dados
semelhantes, uma boa prática é utilizar o conceito de triangulação, que consiste em implementar uma
solução que atenda a todos os casos que se assemelham. Geralmente, na implementação deste conceito, os
testes anteriores já garantem o sucesso no resultado dos semelhantes, portanto o resultado deste teste de
triangulação deve ser verde.

A execução dos testes deve ser isolada, ou seja, um teste não pode interferir no outro. Além disso,
os testes devem ser de rápida execução, permitindo que a cada momento sejam executados para verificar a
integridade do código. Isto dá ao desenvolvedor a segurança de que qualquer refatoração será testada e
caso “quebre” algo que já estava construído, o sinal vermelho será mostrado na execução dos testes. O TDD
servirá como um guia do desenvolvimento, mostrando toda a evolução do código, ou seu histórico de
implementação, podendo ser utilizado até mesmo como um manual de utilização para que outros
desenvolvedores utilizem as classes e métodos criados. Outras vantagens serão abordadas no decorrer deste
trabalho.

4
 TDD – Test Driven Development – Desenvolvimento guiado por testes

3. Princípios de desenvolvimento
Na Engenharia de Software Ágil existem vários princípios de desenvolvimento que também podem
ser chamados de boas práticas. Estas “técnicas”, difundidas na literatura e nas comunidades de
desenvolvimento de software com o tempo, objetivam melhorar as práticas de engenharia, facilitando,
simplificando e melhorando cada vez mais o design e a construção de aplicações. Seus princípios fazem parte
do TDD, o qual prega pela simplicidade em sua concepção. Tais siglas e termos peculiares ajudam na fixação
e as fazem mais populares, como pode ser visto:

3.1. KISS - Keep It Simple, Stupid

O acrônimo em inglês quer dizer “Mantenha isso simples, estúpido”. Valoriza a simplicidade no
desenvolvimento dos projetos e, por conseqüência, do código. É utilizada no TDD, pois parte do princípio de
fazer apenas o necessário e de forma mais simples possível. Essa filosofia não é utilizada apenas na
Engenharia de Software, mas também em várias outras áreas de conhecimento.

Dentre os benefícios do KISS, estão:

• Resolução de problemas mais rapidamente.

• Produção de um código para resolver problemas complexos em menos linhas de código.
• Produção de código de qualidade superior.
• Construção de sistemas maiores, mais fáceis de manter.
• Capacidade de trabalhar com grandes projetos, já que todo o código é simples e estúpido.

3.2. YAGNI - You Ain’t Gonna Need It

Este é um dos princípios mais curiosos e ao mesmo tempo fascinante. O termo em português
significa: “Você não vai precisar disso”. Segundo YAGNI, você não deve adicionar uma funcionalidade até que
ela seja necessária, ou seja, implemente apenas quando realmente precisar e nunca quando você prevê que
precisará dela no futuro.

De acordo com aqueles que defendem esta abordagem, a tentação de escrever um código não
necessário no momento, mas que poderá ser no futuro, tem algumas desvantagens:

• Os novos recursos devem ser testados, documentados.

• Qualquer novo recurso impõe restrições sobre o que pode ser feito no futuro. Portanto, um
recurso desnecessário agora pode impedir execução de uma característica necessária mais
tarde.
• Até que o recurso seja realmente necessário, é difícil definir completamente o que ele deve
fazer. Se o novo recurso não está devidamente definido e testado, ele pode não funcionar
corretamente.
• Adicionando o novo recurso, novas “funcionalidades” podem surgir. Se estes novos recursos são
implementados, isso pode resultar em um efeito bola de neve.

3.3. Fake it, till you make it

Em português, significa “Simule isso enquanto puder”. Prática muito utilizada no TDD e que tem
relação com a YAGNI. Esta técnica implica em simular uma funcionalidade do desenvolvimento até que você
realmente precise implementá-la realmente. Isso faz com que você mantenha a simplicidade ao máximo

5
 TDD – Test Driven Development – Desenvolvimento guiado por testes

durante desenvolvimento, o que contribui para um bom design. Outra vantagem dessa técnica é a garantia
de que o que é simulado está totalmente confiável e correto, evitando a suspeita de problemas no
desenvolvimento e testes de outras funcionalidades.

3.4. ATDD - Acceptance TDD

O ATDD é uma prática utilizada em equipes num nível mais alto de maturidade, as quais utilizam TDD
em testes de aceitação. Em português, significa “Desenvolvimento Dirigido a Testes de Aceitação”. Tem
como princípio automatizar os testes de baseados nos critérios e requisitos especificados pelo cliente.

A prática garante que o cliente tenha um mecanismo de validação automatizado que mostre que o
software atende às suas necessidades. Os testes são desenvolvidos pela equipe de acordo com as reuniões
de planejamento, por exemplo, enquanto discutem cada estória e o cliente define o que fará aquela
funcionalidade satisfatória para o negócio. Esta técnica exige que o cliente tenha um nível de maturidade e
conhecimento no assunto para tirar proveito do trabalho.

3.5. DRY - Don´t repeat yourself ou DIE - Duplicate is Evil

As siglas que já falam por si mesmo, em português dizem: DRY: Não se repita e DIE: Duplicar é mau.
A prática prega a redução de duplicação de informações de todos os tipos dentro de um projeto. Aplicado à
Engenharia de Software, o princípio sugere que cada pedaço do conhecimento dentro de um software deve
ter apenas uma apresentação.

Essa parte deve ser autoridade daquele conhecimento específico dentro do sistema. Quando o
princípio é utilizado consistentemente no sistema, uma alteração em um elemento individual não altera
qualquer área de conhecimento que esteja logicamente independente e, em contrapartida, elementos
relacionados são mantidos em sincronia, evitando possíveis falhas e alto custo de manutenção.

Máximas de grandes nomes que influenciaram esses princípios:

“Faça tudo o mais simples possível, não o mais fácil.” (Albert Einstein)
“A simplicidade é a sofisticação final.” (Leonardo Da Vinci)
“A perfeição é alcançada não quando não temos mais nada à acrescentar e sim quando não temos mais
nada para retirar.” (Antonie de Saint Exupéry)

4. Cenários
O TDD - ao contrário do que aparenta à primeira vista - pode ser aplicado em vários cenários de
desenvolvimento de software. A construção de uma aplicação orientada a testes desde a concepção da ideia
é o caminho ideal e de menor custo de implantação. Porém, isso não impede que a metodologia seja
aplicada em outros ambientes que não este. Vamos tratar de três cenários bem diferentes e vamos pontuar
suas características. Obviamente, todos os casos têm suas peculiaridades que dependem da realidade e ao
dia-a-dia de cada projeto.

6
 TDD – Test Driven Development – Desenvolvimento gui
guiado por testes

4.1. TDD desde o início

O primeiro cenário é a implantação da metodologia na sua essência. Um cenário onde o projeto

adota a prática desde sua concepção. O caminho feliz. Nesse cenário devem ser seguidas todas as diretivas
do TDD para obter o máximo de resultado que a prática oferece.

Lembrando que TDD não se tratatrata de desenvolvimento de testes e sim desenvolvimento de software
orientado a testes, ou seja, a construção dos testes influencia diretamente no design da aplicação.

Veja o fluxo de iteração do TDD aplicado em projetos recém-nascidos:

recém

Dicas:

• Manter a compatibilidade com versões pode ser uma boa opção no caso de desenvolvimento de
APIs.
• Transformar casos extremos em testes na robustez do projeto.

4.2. TDD na correção de bugs

Outro cenário onde o TDD pode ser aplicado é na correção de bugs de um sis sistema que não foi
construído baseado na metodologia. Este modelo se mostra atraente, pois o teste inevitavelmente faz parte
da correção de bugs em um sistema que já “funciona”. Assim, o TDD tem a vantagem de “catalogar” os
testes feitos para a correção de problemas
roblemas que ocorrerão com o tempo. Quanto mais bugs vão surgindo,
mais cresce a cobertura de testes do sistema. Tal vantagem traz o benefício dos bugs não se repetirem e não
causarem impacto em outras partes do sistema já cobertas por testes, pois,
pois de acordo
ordo com a metodologia,
metodologia
testes escritos anteriormente nunca podem ser quebrados.

Fluxo de iteração do TDD aplicado na correção de bugs em um sistema não coberto por testes:

7
 TDD – Test Driven Development – Desenvolvimento guiado
gui por testes

Passo a passo

• Encontre o foco do problema que gera o bug

• Transforme-o em um teste
• Teste. Ele deve falhar
• Corrija o bug
• Teste novamente. Ele deve passar

Dicas

• Tente fazer com que usuários submetam testes ou casos de testes, mesmo que de forma não não-
técnica, pois isso facilita a criação de suas assertivas. O usuário final é quem mais tem conhecimento
de um sistema.
• Examine o código e encontre possíveis falhas semelhantes onde o teste escrito possa ser
reaproveitado, cobrindo assim mais uma parte do sistema.

Nota: estee modelo pode ser aplicável em sistemas construídos com TDD.
TDD Neste caso a correção de bugs
consiste na manutenção dos testes existentes.

4.3. TDD em código legado

Este é, certamente, o cenário mais complexo para aplicação do TDD. Código legado não coberto por
testes automatizados corresponde a um grande e custoso débito técnico do sistema. Normalmente o
conhecimento aplicado neste tipo de software é detido por poucas pessoas e na maio maioria das vezes não
possui uma documentação fiel à realidade. Outro problema grave encontrado neste
nes e cenário é o impacto,
impacto
muito difícil de ser estimado.

Fluxo de aplicação do TDD em sistemas de código legado:

8
 TDD – Test Driven Development – Desenvolvimento guiado
gui por testes

Passo a Passo

• Analise o código
• Construa o teste e certifique-se
se
que você entendeu o problema
• Teste. Deve falhar
• Adapte o teste (iterativamente)
terativamente)
• Teste. Deve passar
• Siga para a próxima parte

Ao implementar...

• Entenda
• Documente
• Refatore
• Remova excessos
• Padronize
• Faça-o seguro e robusto

Dicas

• CUIDADO!
• Vá devagar
• Esteja pronto para desfazer tudo

9
 TDD – Test Driven Development – Desenvolvimento guiado por testes

5. Mocks, Stubs, Dummies e Fakes

5.1. O que fazer com as Dependências?

Durante a construção dos testes unitários, como o próprio nome já diz, o desenvolvedor está
concentrado em um elemento do software por vez, (até porque, quando um teste utiliza mais de um
elemento ele é chamado de teste de integração) mas nos sistemas estes elementos geralmente referenciam
outros, portanto, o que fazer para resolver estas dependências e evitar o acoplamento?

5.2. Dublês de Teste

Uma forma de resolver esta situação é a utilização dos dublês de teste, cuja origem vem dos stunt
doubles (sim, os dublês de filmes!).
Um dublê é uma representação falsa de um objeto real. Eles são bastante úteis durante o
desenvolvimento dos testes, uma vez que nem sempre o elemento que você precisa está pronto ou o teste é
dispendioso.

5.3. Tipos de Dublês

• Mock: simula objetos reais de forma controlada dentro dos testes. Isso nos ajuda quando o objeto
real é muito complexo, lento ou ainda nem existe (Banco de Dados, recursos em rede...). São pré-
programados com informações que formam uma especificação das chamadas que esperam receber.
• Stubs: providenciam respostas pré-configuradas para as chamadas feitas durante os testes,
normalmente não respondem a nada que não esteja programado para o teste. Um exemplo de uso
de stubs seria a implementação de um despertador, que para determinada hora utiliza um alarme
diferente. Sem o stub, o teste precisaria esperar até a hora X para ser executado.
• Dummy: é repassado, mas nunca utilizado. Normalmente são usados para preencher listas de
parâmetros.
• Fakes: têm implementações funcionais, mas normalmente utilizam algum atalho que os torna
inadequados para produção (uma base de dados em memória é um exemplo).

6. Integração do TDD ao Scrum

O TDD vem completar o Scrum no que tange à qualidade. A máxima “se você não testa, você não é
ágil” nos dá uma ideia desta parceria. Enquanto o Scrum isolado já possibilita desenvolver projetos com
transparência e agilidade, Scrum aliado ao TDD entrega projetos com nível de qualidade superior e
especificação das classes utilizadas, auxiliando consideravelmente na organização e documentação do
projeto. Dentre as mudanças que o TDD traz para o Scrum estão:

• Na reunião de planejamento
o Elevação do comprometimento do time
o Planejamento mais rápido

10
 TDD – Test Driven Development – Desenvolvimento guiado por testes

• Na reunião de revisão
o Os testes passam a fazer parte da demonstração do que é potencialmente entregável

• Na reunião de retrospectiva
o São considerados Scrum e TDD na discussão do que é ou não entregável

TDD + Scrum promove uma sinergia – ou seja – os benefícios resultantes da soma dos dois
elementos impactam no processo em proporção bem maior do que simplesmente a junção “TDD + Scrum”.

No gráfico a ao lado é possível notar

o crescente aumento do nível de qualidade
após a adoção do TDD em projetos que já
utilizavam Scrum. Nota-se, também, que a
curva de motivação do time e produtividade
alcança níveis estáveis, após a
preparação/adaptação ao TDD.

Conclui-se, assim, que o resultado da

junção TDD + Scrum são projetos andando,
com revisões freqüentes para
correção/entrega de valor para o cliente,
nível de qualidade protegido e especificação
das classes de código.

7. Confusões com TDD

Existem vários mitos e confusões em torno de TDD. Dentre eles, estão:

• “TDD pode gerar um conjunto de testes 100% aplicável para qualquer aplicação”: Há os
componentes comprados prontos/baixados/reutilizados que às vezes deixam de ter até o
código-fonte. Sistemas legados também requerem atenção especial, pois pode não ter sido
escrito ainda o teste específico para alguma parte de um sistema deste tipo.

• “Você só precisa fazer o teste de unidade”: É preciso aplicar outras técnicas de teste, mesmo
para os sistemas mais simples.

• “TDD é suficiente para testar tudo”: TDD contempla o teste entre o desenvolvedor e a unidade.
Outros testes (como de aceitação, por exemplo) devem ser feitos.

• “TDD não é escalável”: O TDD encoraja o refactoring, o que torna o código escalável. Este mito é
geralmente reforçado por aqueles que não sabem como aplicar o TDD.

11
 TDD – Test Driven Development – Desenvolvimento guiado por testes

8. Cinco desculpas para não usar TDD

Apesar de se tratar de uma técnica criada para facilitar o desenvolvimento, há desculpas para
aqueles que não admitem adotá-la. As mais comuns são:

• “Vai demorar muito mais”: uma das desculpas mais populares, utilizada inclusive pelos gerentes
que se enganam, pensando que ter qualquer coisa “pronta” é sinal de produtividade. Só que a
maioria das pessoas adeptas desta desculpa pensa que o tempo de desenvolvimento de uma
funcionalidade é só aquele utilizado para entregá-la. Supondo que uma pessoa produziu todo o
seu código utilizando basicamente seus instintos e disse “terminei” sem nenhum tipo de
validação, os riscos de ter alguma coisa incorreta aumentam bastante. E é neste ponto que TDD
apresenta uma vantagem. O programador é obrigado a explorar melhor o problema, e ao
terminar de codificar já terá uma série de testes automatizados para mostrar que aquilo que foi
feito funciona. Ou seja, para entregar pode até ser que demore mais, mas para ter uma
funcionalidade de acordo com os requisitos e sem defeitos o tempo provavelmente será menor.

• “A funcionalidade é muito fácil”: se depois de uma breve avaliação o sujeito achar que a solução
a ser programada é muito fácil, ele está correndo três riscos: 1) não entendeu todas as variações
do problema; ou 2) vai programar com displicência; ou 3) planeja usar e abusar de um dos piores
inimigos da programação, o Ctrl+C, Ctrl+V. Em todos os casos a possibilidade de fazer besteira é
iminente e poderia ser diminuída com testes, onde o problema seria explorado melhor antes do
código e haveria a chance de remover a duplicação de código com auxílio de testes. Estes testes
também confirmariam que a mudança não quebrou outra parte do sistema, o que indica que
deveria haver testes para todo o sistema.

• “Não sei como testar”: quem está começando a usar TDD tem essa desculpa na ponta da língua.
É como se não conhecesse uma biblioteca e isto o impedisse de programar. Mas programar
orientado a testes não é tão difícil assim, afinal se trata apenas de programação, coisa que já
estamos acostumados. Basta pensar no problema que as perguntas surgem e aí estão os testes.
Escreva a pergunta, pense na resposta e a escreva também. Com o tempo as perguntas vão
ficando melhores, mas não saber fazê-las não pode ser a razão para não começar.

• “Isso não dá pra testar”: este é um mito que não tem fundamento. Tudo é testável, embora
alguns casos sejam mais difíceis ou exijam um pouco mais de pesquisa. Dificilmente você terá
um cenário que outros não tenham conseguido testar, e neste caso é só aprender como se faz.
Se ainda assim o cenário for inédito na literatura, existe uma comunidade grande sempre
disposta a ajudar, então só basta querer. Ah! E na maioria dos casos usar mocks e stubs
resolvem os problemas ditos como “não testáveis” pelos iniciantes.

• “Melhor deixar os testes com os testadores”: aqui é um exemplo de que não se entendeu pra
que serve TDD afinal. Escrever testes de unidade por si só não significa programar orientado a
testes, uma vez que os testes são escritos antes do código existir e de maneira incremental.
Então deixar os testes com os testadores significa abrir mão de uma ferramenta de modelagem
simples, pensando que esta se trata apenas de testes.

12
 TDD – Test Driven Development – Desenvolvimento guiado por testes

9. Vantagens Desvantagens
Vantagens

• O código é inerentemente testável.

• O desenvolvimento dirigido por testes oferece mais do que somente uma maneira simples de
validação e de correção, ele pode orientar o design de uma aplicação.
• Melhora o entendimento dos engenheiros com o negócio do sistema, pois o engenheiro deve
entender o problema e o que deve ser verificado antes de projetar a solução.
• A arquitetura tende a apresentar baixo nível de acoplamento.
• Maior confiança no código produzido, já que os testes cobrem todos os impactos causados por
alterações no sistema.
• Mesmo que usando o TDD a quantidade de código seja maior, o tempo total de implementação é
tipicamente menor.
• Códigos gerados assim geralmente não apresentam problemas posteriores.
• Testes de alta qualidade: quando se implementa os testes após o código estar pronto, tende-se a
implementar testes de baixa qualidade, pois inconscientemente escreve um teste para rodar no
código produzido.
• Quando acabamos realmente acabamos.

Desvantagens

• Mudança de cultura: é necessário o apoio gerencial, caso contrário o tempo necessário para
escrever os códigos será considerado desperdício. Para um desenvolvedor já é difícil mudar sua
mente em favor dos testes e TDD. Deverá haver esforço necessário para que um gerente o entenda.
• Quem cria os testes é o próprio desenvolvedor. Portanto, erros conceituais poderão continuar
existindo na aplicação.
• Os próprios testes se tornam parte da manutenção do sistema.

10. Conclusão
O processo de desenvolvimento orientado a testes é mais rápido do que parece ser. O tempo gasto
no fim do desenvolvimento de uma funcionalidade pode, em alguns casos, ser até mais rápido do que o
normal, levando em consideração a prática de implementar a solução mais óbvia possível.

A mensagem final que o TDD nos deixa é que, quando acabamos, realmente acabamos. É pouco
provável que após o término seja necessário retornar ao código para corrigir alguma falha, já que essas
foram detectadas e solucionadas durante a construção. Além disso, o principal ganho se dá quando o código
exige evoluções.

Qualquer impacto gerado pela alteração do sistema será mostrado pelos testes, simples e rápidos de
serem executados. Sendo assim, uma alteração pode ter sua eficiência validada com baixíssimo esforço e
grande segurança.

É preciso ressaltar que o processo não é infalível, mas, quando bem utilizado, traz grandes ganhos
visto que o código-fonte desenvolvido raramente apresenta problemas.

13
 TDD – Test Driven Development – Desenvolvimento guiado por testes

Recapitulando, as três premissas básicas do TDD são:

1. Escrever um teste que não irá funcionar.

2. Fazer com que esse teste funcione com a implementação mais óbvia e rápida possível.
3. Repetir este ciclo iterativamente, refatorando o código, eliminando duplicações e a facilitando a
legibilidade.

No início, trabalhar com TDD exige uma mudança de cultura e pode parecer oneroso, pois é uma
quebra de paradigma da forma que trabalhamos normalmente. Este processo inicial e doloroso de
aprendizado dá lugar a outro sentimento, à medida que a prática traz eficiência e os ganhos são percebidos.
Os problemas que acontecem no cotidiano do desenvolvimento de um software acarretam prejuízo aos
clientes. E para nós – desenvolvedores - o esforço gasto ao utilizar TDD é recompensado.

11. Bibliografia
• www.scrumalliance.org/resource_download/267
• http://people.apache.org/~fhanik/kiss.html
• http://www.inf.ufsc.br/~sanchez/dojo/screencast_tdd.htm (vídeo com implementação)
• http://javafree.uol.com.br/files_user/files/9/36/CC/RobertoAlencar_Artigo_TDD.pdf
• http://dojofloripa.wordpress.com/2007/09/10/tudo-sobre-tdd/
• http://www.slideshare.net/Skud/test-driven-development-tutorial
• http://www.improveit.com.br/xp/praticas/tdd
• http://www.slideshare.net/nashjain/test-driven-development
• http://www.inf.ufrgs.br/~cesantin/TDD-Otavio.pdf
• http://www.infoq.com/br/search.action?queryString=TDD
• http://www.agiledata.org/essays/tdd.html (Bastante coisa sobre TDD)
• http://gbuchoa.blogspot.com/2010/08/devsrnimbus-scrum-tdd.html
• http://tasafo.wordpress.com/2009/05/14/se-voce-nao-testa-voce-nao-e-agil/
• http://www.sagadoprogramador.com.br/tag/tdd/
• http://www.inf.ufrgs.br/~cesantin/TDD-Otavio.pdf
• http://javafree.uol.com.br/files_user/files/9/36/CC/RobertoAlencar_Artigo_TDD.pdf
• http://viniciusquaiato.com/blog/tdd-test-driven-development-c-parte-ii/
• http://www.infoq.com/br/presentations/dnad-mauricio-aniche
• http://vimeo.com/13635357
• http://www.aniche.com.br/2010/11/cuidado-com-seus-baby-steps/

14