TDD: fundamentos do desenvolvimento orientado a

testes
Apesar de muitas empresas ainda no utilizarem tcnicas de teste de software
para o desenvolvimento dos seus produtos, alegando o atraso, o tempo ou o
custo para esta tarefa, as pesquisas indicam que os testes ajudam na garantia
de qualidade do software.
Vamos a outra realidade, imagine voc adquirindo um carro, que foi projetado,
montado, mas sem ser testado, pois os testes sairiam muito caro, e de repente
voc est andando e nota que na curva o carro no eficiente. Voc ficaria
contente com esta situao? O mesmo acontece com o cliente de um software
ao adquirir um produto que no funciona adequadamente. O Standishgroup,
no relatrio de chaos, apresenta constantemente o resultado da pesquisa e
demonstra que o percentual de software tido como completo e aceitvel
muito baixo. Alm disso, segundo Myers apud. Barti, quanto mais
tardiamente descobrirmos os erros, mais caros estes se tornam. Aplicando-se
assim a regra dos 10 ao custo da correo, ou seja, encontrar um erro durante
o requisito custa 1, por exemplo, durante a fase de anlise e modelagem, custa
10, durante a codificao custa 100, durante a fase de teste, ps
desenvolvimento, custa 1.000 e durante a produo, ou seja, quando j est na
mo do cliente, o processo custa 10.000. Desta forma, importante que a fase
de requisitos possua validaes, evitando-se assim problemas de entendimento
de requisito.
Os problemas de requisitos so reduzidos quando se utiliza de metodologias
geis, isto por que o cliente acompanha o processo e como os ciclos so
curtos, a velocidade da correo tambm o . Mas como muitas empresas
negligenciam o teste durante a fase de desenvolvimento, os erros s so
encontrados tardiamente, elevando os custos dos produtos e criando impactos
negativos aos processos e negcios.
Temos de lembrar que qualidade no uma etapa apenas, uma fase do
desenvolvimento, parte de todo o ciclo de vida de desenvolvimento do
software.
Mas o que qualidade no processo de desenvolvimento de software? Segundo
Barti Qualidade de software um processo sistemtico que focaliza todas as

etapas e artefatos produzidos com o objetivo de garantir a conformidade de

processos e produtos, prevenindo e eliminando defeitos.
A qualidade aplicada tardiamente no gera um produto com qualidade, Barti
afirma que a maioria das organizaes aplicam em seus processos de
desenvolvimento testes tardios, o que no garante a qualidade do produto, e
como vimos na regra de Myers, o custo do produto aumenta
consideravelmente. Ainda segundo Miller apud Presmann, a motivao que
est por trs do teste de programas a confirmao da qualidade de software
com mtodos que podem ser economicamente e efetivamente aplicados a
todos os sistemas, de grande e pequena escala. Desta forma, utilizar uma
metodologia que permita testes no processo de desenvolvimento, auxilia na
garantia de qualidade.

O TDD
O TDD (Test Driven Development / Desenvolvimento orientado a teste)
parte da metodologia XP e tambm utilizado em diversas outras metodologias,
alm de poder ser utilizada livremente.
O que voc tem a perder utilizando o TDD?
Bem segundo Freeman at al, voc no tem nada a perder, a no ser os seus
bugs.
O TDD transforma o desenvolvimento, pois deve-se primeiro escrever os
testes, antes de implementar o sistema. Os testes so utilizados para facilitar
no entendimento do projeto, segundo Freeman os testes so usados para
clarear a ideia em relao ao que se deseja em relao ao cdigo. Segundo
Kent Beck apud Freeman Finalmente, consegui separar o projeto lgico do
fsico. Sempre me disseram para fazer isso, mas nunca ningum tinha
explicado como, o TDD a forma de se fazer isso. A criao de teste
unitrios ou de componentes parte crucial para o TDD. Segundo Presmann,
Os componentes individuais so testados para garantir que operem
corretamente. Cada componente testado independentemente, sem os outros
componentes de sistema. Os componentes podem ser entidades simples, tais
como funes ou classes de objetos, ou podem ser grupos coerentes dessas
entidades.

Mas no s o teste unitrio que vai trazer o sucesso a aplicao, necessrio

testar o sistema como um todo, que segundo Sommerville, Os componentes
so integrados para compor o sistema. Esse processo est relacionado com a
busca de erros que resultam das interaes no previstas entre os
componentes.
Um sistema um conjunto de unidades integradas, por este motivo
importante os testes unitrios para ver se no micromundo tudo funciona, mas
tambm temos de testar a integrao, ou seja, ao integrar dois ou mais
componentes, devemos realizar testes para verificar se a integrao funciona.
Voltemos ao exemplo do carro, no adianta eu testar a roda, a porta, o volante,
mas no testar o carro completo. Erros podem ocorrer, justamente no processo
de montagem/integrao de componentes.
E qual o benefcio em utilizar o TDD?
Em primeira instncia, torna o processo mais confivel, mas reduz custos, pois
desenvolvemos e j sabemos o erro, pois como os testes so criados antes do
processo de desenvolvimento, conseguimos testar constantemente. Outro
ponto que se os testes foram criados, isso quer dizer que foram entendidas as
regras de negcio durante a fase de desenvolvimento dos testes unitrios.
Alm disso, evita retrabalho da equipe, que ao final reduz custo e tem maior
chance de sucesso.
O Ciclo do TDD simples: criamos um teste -> Fazemos a codificao para
passar no teste ->Refatoramos nosso cdigo, conforme figura a seguir:

Figura 1: Ciclo do TDD

Notemos aqui que o teste visa auxiliar a codificao, reduzindo
consideravelmente os problemas na fase de desenvolvimento. No TDD
indicado que o projeto de teste unitrio ocorra antes da fase de
codificao/implementao.
O Teste antes da codificao, ou test-first, segundo Sommerville, a escrita de
testes primeiro define implicitamente tanto uma interface como uma
especificao do comportamento para a funcionalidade que est sendo
desenvolvida.
Note que ao criar o teste antes de implementar a unidade, so reduzidos
problemas como mal entendimento de requisitos ou interfaces, pois como
criar um teste se eu no sei o que devo testar?
Neste caso o desenvolvedor, para implementar os testes iniciais, deve
compreender com detalhes a especificao do sistema e as regras de negcio,
s assim, ser possvel escrever testes para o sistema. Imagine o caso de
querer testar um pneu criado para o carro, se no entendi que o pneu
redondo, por exemplo, criarei um teste para um pneu quadrado, no podendo
ser realizado o teste. Desta forma, de extrema importncia, para o
desenvolvedor, o entendimento dos requisitos do cliente. Alm disso, no
adianta criar testes que no validem o cdigo como um todo para reduzir o
tempo, necessrio criar testes para o conjunto completo de unidades, s

assim o TDD vai funcionar como deve, devendo fornecer uma cobertura
completa aos testes.
Alm disso, os testes devem seguir o modelo F.I.R.S.T.
F (Fast) - Rpidos: devem ser rpidos, pois testam
apenas uma unidade;
I (Isolated) - Testes unitrios so isolados, testando
individualmente as unidades e no sua integrao;
R (Repeateble) - Repetio nos testes, com resultados de
comportamento constante;
S (Self-verifying) - A auto verificao deve verificar se
passou ou se deu como falha o teste;
T (Timely) - O teste deve ser oportuno, sendo um teste
por unidade.
Atualmente, existem diversas ferramentas que analisam as coberturas de teste,
podendo ser baixadas gratuitamente da Internet.
Outra vantagem de possuir testes a chamada regresso. Imagine que criamos
os testes, fizemos o sistema e tudo foi entregue ao cliente, mas posteriormente
o cliente pediu pequenas modificaes no sistema, mas no nas regras de
negcio. Os testes j prontos serviro para validar se as modificaes no
criaram problemas nas regras de negcio que j estavam em funcionamento.
Este procedimento exige que testes unitrios estejam prontos, aguardando ser
reutilizados. Logo, segundo Silveira at al., Um teste de unidade deve garantir
que a execuo daquele trecho mnimo de cdigo esteja correta.

Como implementar o processo de TDD ao

desenvolvimento?
Para comear a desenvolver seus primeiros testes, pode ser mais fcil a
utilizao de bibliotecas XUnit's. Existem diversas ferramentas que
possibilitam esta prtica, vamos a algumas:

 JUnit: O JUnit um framework de teste para Java, que

permite a criao de testes unitrios. Alm disso, est
disponvel como plug-in para os mais diversos IDE'S
como Eclipse, Netbeans etc.
TesteNG: Outra ferramenta de teste unitria, disponvel
para Java;
Depois, temos de iniciar a fase de desenvolvimento, criando
primeiramente os testes. Nos sites das ferramentas existe
documentao para saber como utiliz-las, mas possvel ver
nestes tutoriais como utilizar algumas delas:
Introduo ao desenvolvimento guiado por teste: TDD
com JUnit
Como vimos, existem ferramentas para as mais diversas linguagens e
plataformas, com integrao a IDE's. E lembre-se: primeiro crie os testes, para
posteriormente efetuar a sua implementao.

Concluso
Neste artigo vimos o TDD e sua importncia para a qualidade de software.
Foram apresentadas ainda algumas ferramentas que permitem a utilizao dos
testes. Este artigo tem como principal objetivo apresentar fundamentos do por
que utilizar testes na fase de codificao e sua importncia para a reduo de
falhas. Vimos que a utilizao de teste durante a fase de desenvolvimento
melhora a qualidade e reduz custos de manuteno.