A Relao Entre Desenvolvimento Orientado a Testes

e Qualidade de Software
Cssio L. Ribeiro1
1
Instituto de Informtica Pontifcia Universidade Catlica de Gois (PUC Gois)
Goinia GO Brasil
cassio.landim@gmail.com

Abstract. This paper shows how the consequences of the use of test-driven de-
velopment affect the quality of software. It lists some situations that negatively
affect the quality of software, such as the lack of unit testing and presence of
disorganized code. It demonstrates how the use of test-driven development miti-
gates or eliminates the occurrence of these situations. Finally, it highlights other
important quality factors that the test-driven development does not resolve pro-
perly.

Resumo. O presente artigo evidencia de que maneira as consequncias do em-

prego do desenvolvimento orientado a testes afetam a qualidade de um software.
So listadas algumas situaes que afetam negativamente a qualidade de um
software, como a ausncia de testes unitrios e a presena de cdigo desorga-
nizado. Demonstramos como o emprego do desenvolvimento orientado a testes
ameniza ou elimina a ocorrncia dessas situaes. Ao final, evidencia outros
fatores importantes para a qualidade, que o desenvolvimento orientado a testes
deixa a desejar.

1. Introduo
A natureza ubqua da computao moderna, software e infraestrutura de informao e,
ainda, a demanda crescente por automao e convenincia pela sociedade moderna tem
gerado constante aumento de tamanho e complexidade dos sistemas de software moder-
nos. Este incremento em tamanho e complexidade acaba por causar consequncias no-
intencionais em termos de gerar problemas de qualidade [Tian 2005].
A alta complexidade e o amplo escopo dificultam a preveno ou eliminao de
problemas de software e seus impactos negativos relacionados; consequentemente, vrias
atividades de garantia da qualidade so realizadas para prevenir e/ou eliminar certas clas-
ses de problemas, ou ainda, para reduzir a probabilidade ou severidade de tais impactos
quando no se pode evit-los [Tian 2005].
As metodologias geis emergiram da necessidade de se minimizar os riscos do
desenvolvimento de softwares. Essas metodologias evoluram como parte de uma rea-
o contrria aos processos de desenvolvimento utilizados na poca, caracterizados como
pesados, burocrticos, micro-gerenciados e com uma alta tendncia a se produzir docu-
mentos formais [Langr 2005].
Como o desenvolvimento orientado a testes (Test-Driven Development - TDD)
uma prtica fundamental da Programao Extrema (eXtreme Programming - XP), que est
comeando a ganhar uma ampla aceitao entre as entidades desenvolvedoras de software,
este estudo visa evidenciar de que maneira o emprego do TDD afeta a qualidade de um
software.

2. Conceitos de Qualidade de Software e TDD

2.1. Qualidade de Software
[Tian 2005] coloca a qualidade sob a perspectiva das expectativas dos usurios de soft-
ware. Em geral, o que as pessoas esperam como qualidade em um sistema de software
que eles faam o que foram programados para fazer. Em outras palavras, eles devem
fazer a coisa certa, ou seja, eles devem executar suas tarefas especficas corretamente ou
satisfatoriamente.
Comportamentos inesperados se manifestando na forma de defeitos, podem afetar
profundamente a qualidade de um software, porm, este no o nico fator que deter-
mina a qualidade. Segundo [Friedman 2009], as metodologias geis tratam o processo
de incremento da qualidade como um exerccio de eliminao do desperdcio onde o
conceito de desperdcio assume o mesmo significado no contexto da manufatura lean
1
[James P. Womack 1990], onde um produto de alta qualidade aquele que previne o
desperdcio do esforo investido pelo usurio no processo de produzir algo de valor.
[Friedman 2009] identifica trs fatores principais de desperdcio que reduzem a
qualidade de um software. O primeiro e mais comum so os defeitos. Estes podem ser
categorizados como ocorrncias onde o sistema se comporta de forma inesperada. En-
quanto o desenvolvedor espera que o sistema se comporte de certa maneira, o comporta-
mento exibido diferente devido a defeitos inseridos na fase de codificao. O problema
que quando um defeito afeta o usurio, em casos menos graves, pode forar o usurio
a repetir alguma ao, enquanto que em casos extremos pode causar uma perda substan-
cial de dados que ir requerer um esforo significativo para serem reproduzidos (quando
possvel).
O segundo fator est ligado a problemas de usabilidade, onde um produto de di-
fcil uso causa um desperdcio de esforo. Em casos extremos, os usurios fazem uso
de caminhos alternativos para atingirem seus objetivos; entretanto, em vrios casos, os
usurios empregam a forma incorreta de execuo ao invs de perceber que a qualidade
atual do sistema insuficiente para atender seus propsitos.
O terceiro fator, funcionalidades do sistema que no so utilizadas, tambm repre-
sentam um fator de desperdcio. Alm de inteis, retardam e dificultam o uso do sistema.
Esta a forma de desperdcio que mais despende esforos para ser localizada e eliminada.

2.1.1. Verificao versus Validao

Verificao provar que o produto atende corretamente os requisitos especificados em

atividades prvias durante o ciclo de vida de desenvolvimento, j a validao checa que o
1
O termo lean foi cunhado ao final da dcada de 80 em um projeto de pesquisa do Massachusetts Institute
of Technology (MIT) sobre a indstria automobilstica mundial. A pesquisa revelou que a Toyota havia
desenvolvido um novo e superior paradigma de gesto nas principais dimenses dos negcios (manufatura,
desenvolvimento de produtos e relacionamento com os clientes e fornecedores).
sistema atende os requisitos do cliente ao final do ciclo de vida. Tradicionalmente, teste
de software tem sido considerado um processo de validao, isto , uma fase do ciclo de
vida [Lewis 2004].

2.1.2. Qualidade Externa e Interna

Qualidade externa a qualidade medida pelo cliente, e qualidade interna a qualidade

medida pelas pessoas que possuem acesso ao cdigo, como o caso dos programadores
e arquitetos.
As metodologias geis pregam que a qualidade interna de um software no ne-
gocivel, ela deve ser fixada como tima durante todo o ciclo de vida do software. Al-
gumas equipes, na esperana de reduzir o prazo de entrega, sacrificam temporariamente
a qualidade interna na esperana de que a qualidade externa no sofrer um grande im-
pacto. Esta estratgia muito tentadora em um cenrio em curto prazo. Porm, eventual-
mente problemas de qualidade interna o alcanaro e tornaro aquele software proibitiva-
mente caro de manter ou mesmo incapaz de alcanar um nvel competitvel de qualidade
externa [Beck 1999]. Este fenmeno conhecido como dbito tecnolgico. Segundo
[Friedman 2009], tentar trocar a qualidade por velocidade uma das estratgias mais er-
rneas existentes.

2.2. Testes Unitrios

De acordo com [Lewis 2004], teste unitrio a escala mais micro de testes para testar
funes particulares ou mdulos de cdigos. Tipicamente so feitos pelo programador e
no por testadores, j que requerem um conhecimento detalhado do cdigo e do design
interno do software. Nem sempre so fceis de se implementar a no ser que a aplicao
tenha uma arquitetura muito bem desenhada com cdigo organizado.
[Bellware 2009] acredita que quando testes so escritos aps o cdigo de produo
j estar pronto, na realidade o que se est fazendo um tipo de engenharia reversa, que
uma forma de engenharia de que exige uma grande quantidade de esforo. Exige muito
esforo porque ao se escrever os testes neste momento, o programador precisar ler todo
o cdigo, entender o que ele faz e adivinhar como escrever um teste para este cdigo.
Os testes produzidos desta maneira acabaro, provavelmente, no servindo para cobrir o
mnimo necessrio dos caminhos alternativos de execuo do cdigo.

2.3. Desenvolvimento Orientado a Testes

As metodologias geis j se tornaram populares na rea de desenvolvimento de software.
A cada dia, mais empresas as adotam para amenizar problemas de qualidade e de entrega
de produtos que agreguem o valor real aos seus clientes.
Algumas metodologias geis como Scrum tem foco em prticas gerenciais e or-
ganizacionais, enquanto XP tem foco maior em prticas de programao. O TDD uma
das prticas que fazem parte do ncleo do XP [Beck 1999] que entra em cena durante as
fases de desenho e codificao de um software.
XP uma metodologia gil e leve para equipes de desenvolvimento de software
de tamanho pequeno mdio que lidam com requisitos vagos ou que mudam rapidamente
[Beck 1999]. XP procura melhorar um projeto de software atravs da comunicao, sim-
plicidade, feedback, respeito e coragem. D nfase no trabalho em equipe, permitindo que
os desenvolvedores respondam com confiana s mudanas de requisitos dos clientes, at
mesmo tardiamente no ciclo de vida do projeto.
Scrum um processo gil para o desenvolvimento de projetos, sendo mais ade-
quado para projetos onde os requisitos esto mudando ou emergindo rapidamente. mais
focado nas pessoas e na forma como elas devero interagir entre si para atingir um obje-
tivo comum.
[Schwaber 2004] afirma que o Scrum baseia todas as suas prticas em uma es-
trutura de processo incremental e iterativo. Esta estrutura formada por iteraes de
atividades de desenvolvimento que ocorrem uma aps a outra, sendo que a sada de cada
iterao um incremento do produto. Dentro desta iterao ocorrem vrias iteraes mais
curtas (inspees dirias), onde os indivduos membros do time se encontram para inspe-
cionar as atividades dos outros membros e fazerem as adaptaes necessrias. Uma lista
de requisitos guia a iterao. Este ciclo se repete at que o projeto termine.
Ao incio de cada iterao, o time analisa o que deve ser feito. Ele ento escolhe o
que acredita que possa se tornar um incremento de funcionalidade potencialmente entre-
gvel ao final da iterao. O time deixado a ss para fazer seu melhor esforo pelo resto
da iterao. Ao final da iterao, o time apresenta o incremento de funcionalidade que
construiu para que os patrocinadores do projeto possam inspecion-lo e fazer ajustes para
as prximas iteraes do projeto. O processo criativo durante as iteraes o corao da
produtividade do Scrum.
J o TDD uma prtica que visa aumentar a velocidade da entrega de produtos
atravs da simplificao das atividades de desenho de software. [Koskela 2008] resume a
filosofia do TDD em uma frase somente escreva cdigo para fazer um teste falho passar.
[Astels 2003] define o TDD como sendo um estilo de desenvolvimento onde:
Uma sute exaustiva de testes de programadores mantida;
Nenhum cdigo entra em produo a no ser que tenha testes associados;
Os testes so escritos antes;
Os testes determinam que cdigo precise ser escrito.

2.3.1. Ciclo Teste-Codificao-Refatorao

TDD uma tcnica de desenho e desenvolvimento que nos ajuda a construir um sistema
de forma incremental, com a conscincia de que nunca nos afastamos de uma baseline
funcional e entregvel. O ciclo Teste-Codificao-Refatorao quem dita o ritmo do
desenvolvimento atravs de pequenos e controlados passos. A sequncia clssica que nos
foi ensinada, onde primeiramente produzimos o desenho, implementamos o desenho, e
s ento testamos o software em busca dos defeitos, totalmente invertida quando com-
parada ao ciclo Teste-Codificao-Refatorao.
Primeiramente escrevemos o teste, depois escrevemos o cdigo para fazer este
teste passar e ento passamos para a fase de desenho. Esta fase de desenho diferente da
fase de desenho tradicional. No TDD ela chamada de refatorao, onde o desenho atual
do cdigo transformado em um desenho melhor.
 O ciclo Teste-Codificao-Refatorao tambm pode ser chamado de ciclo
Vermelho-Verde-Refatorao [Astels 2003]. O vermelho simboliza a fase inicial do ci-
clo TDD onde o teste escrito falha. Ele falha porque o sistema no est funcional; ele
no possui as funcionalidades que desejamos que ele tenha. Em alguns ambientes de
desenvolvimento, essa falha evidenciada atravs da exibio de uma barra vermelha.
Na segunda fase implementamos as funcionalidades que faltavam para fazer todos
os testes passarem, ou seja, os testes que j existiam e o novo teste recm-introduzido.
Neste momento, a barra visual deve se tornar verde. Somente se passa para a prxima
etapa quando nenhum teste estiver falho.
Na ltima parte do ciclo feita a refatorao. Refinamos o desenho do cdigo
sem alterarmos seu comportamento externo, mantendo todos os testes passando e a com
a barra visual exibindo a cor verde.

3. A Relao entre TDD e Qualidade

Qualidade no pode ser alcanada atravs da avaliao de um produto j feito. O objetivo,
portanto, prevenir defeitos de qualidade ou deficincias em primeiro lugar, tornando os
produtos avaliveis atravs de medidas de garantia de qualidade [Lewis 2004].
[Beck 1999] cita alguns exemplos de riscos relacionados ao desenvolvimento de
software. Dos riscos citados, dois esto diretamente ligados a qualidade de software e
podem ser tratados atravs da utilizao de TDD:
Taxa de defeitos o software colocado em produo mas a taxa de defeitos to
alta que ele acaba no sendo utilizado. TDD eleva a validao de um software a
um patamar superior, testando-o funo por funo;
Deteriorao do sistema o software colocado em produo com sucesso, porm
aps algum tempo o custo de se fazer modificaes ou a taxa de defeitos aumenta
tanto que o sistema precisa ser substitudo. TDD mantm o programador focado
na soluo, de forma que o software no fica carregado de cdigos desnecessrios,
duplicados ou de difcil manuteno, impedindo a deteriorao do sistema.
Nesta mesma obra, [Beck 1999] elaborou trs frases de impacto, que servem como
um ponto de partida para entendermos como o TDD afeta a qualidade de um software:
Toda vez que algum toma uma deciso e no a testa, existe uma grande probabi-
lidade de que esta deciso esteja errada;
Funcionalidades de software que no podem ser demonstradas atravs de testes
automatizados simplesmente no existem;
Testes nos do chance de pensar sobre o que queremos, independente da forma
como a soluo ser implementada.
Ao utilizar TDD, devemos escrever testes para cada soluo implementada. Dessa
forma, diminumos a probabilidade de tomarmos uma deciso errada. Ao mesmo tempo,
temos a oportunidade de experimentar vrias implementaes diferentes para o mesmo
problema e escolher aquela mais limpa, elegante e que apresente o melhor desempenho.
Na poca em que [Beck 2002] publicou sua obra, afirmou que ainda no haviam
estudos que demonstrassem cientficamente as diferenas na qualidade, produtividade ou
diverso entre a utilizao de TDD e quaisquer outras alternativas. Atualmente j existem
publicados alguns estudos objetivos sobre o impacto da utilizao de TDD com relao
qualidade e produtividade, frente maneira tradicional de desenvolvimento.
Em seu blog, [Hawley 2004] publicou os resultados de uma pesquisa que ele
mesmo realizou com a ajuda de seu colega de trabalho. Nesta pesquisa ele constatou
que 92% dos desenvolvedores perceberam que TDD os foraram a produzir cdigo de
alta qualidade. Constatou tambm, atravs dos cdigos produzidos pelos participantes,
que houve um incremento na qualidade do cdigo, uma vez que eles tiveram 18% mais de
sucesso nos testes de caixa-preta em comparao com os cdigos produzidos da maneira
tradicional.

3.1. Desenho Simplificado e Evolucionrio

Escrevendo somente o necessrio para os testes e removendo toda a duplicao, voc au-
tomaticamente obtm um desenho que perfeitamente adaptado para os requisitos atuais
e igualmente preparado para todas as futuras funcionalidades [Beck 2002].
Design simplificado reduz os custos porque ao escrever menos cdigo para atender
os requisitos, menos cdigo existir para ser mantido no futuro. Design simplificado
mais fcil de se construir, manter e entender.

3.2. Refatorao
Os testes lhe do a confiana de que grandes refatoraes no mudaro o comportamento
do sistema, o que se conclui que, quanto maior a confiana, mais agressivamente voc
poder conduzir refatoraes em larga escala que estendero a vida de seu sistema. A
refatorao torna a elaborao dos prximos testes muito mais fcil [Beck 2002].
Custos so reduzidos porque a refatorao contnua evita que o desenho se degrade
com o passar do tempo, assegurando que o cdigo continue fcil de ser entendido, mantido
e modificado.

3.3. Feedback Constante

[Beck 2002], no ltimo captulo de sua publicao, afirma que TDD o ajuda a dar ateno
aos problemas certos na hora certa, de forma que o desenho do software fica mais limpo
e com muito menos defeitos. O TDD faz com que o programador ganhe confiana sobre
seu cdigo com o passar do tempo, isto , medida que os testes vo se acumulando (e
melhorando), ele ganha confiana no comportamento do sistema. E ainda, medida que
o desenho refinado, mais e mais mudanas se tornam possveis.
Outra vantagem do TDD que [Beck 2002] acredita poder explicar seus efeitos
positivos, a forma como ele encurta o ciclo de feedback sobre as decises de desenho.
Ele dura apenas segundos ou minutos, e seguido pela reexecuo dos testes dezenas ou
centenas de vezes por dia. Ao invs de se projetar um desenho e ento esperar semanas
ou meses para outra pessoa sentir as dores ou glrias de sua consequncia, o feedback
emerge em segundos ou minutos, enquanto voc tenta traduzir suas idias em interfaces
plausveis.

3.4. Sute de Testes (Regresso)

Usando TDD, os testes unitrios so criados num momento onde a funcionalidade a ser
implementada est mais bem definida na mente do programador, e depois podem e devem
ser utilizados para fazer testes de regresso. Uma sute de testes automticos feita por
programadores reduz os custos de um software funcionando como uma rede de segurana
de testes que capturam defeitos, problemas de comunicao e ambigidades antes e per-
mitem que o desenho possa ser modificado de forma incremental. Esta sute de testes
gerada pelo TDD fundamental para viabilizar procedimentos de Integrao Contnua 2 .

3.5. Documentao Para Programadores

A sute de testes serve como uma documentao voltada para o programador que tem um
entendimento mais rpido e facilitado do que uma parte do cdigo faz atravs do cdigo
que o testa. Cada teste unitrio especifica o uso apropriado de uma classe de produo
[Langr 2005].

4. Concluses
Esta tcnica de desenvolvimento produz desenhos menos acoplados que so mais fceis
de manter, reduz altamente a quantidade de defeitos, e refora a construo e manuteno
apenas do que realmente necessrio. Finalmente, testes bem escrito atuam como um
tipo de requisitos executveis que ajudam a manter o entendimento compartilhado da
equipe de desenvolvimento, sobre como o sistema de software representa os problemas
do mundo real.
Por outro lado, o fato de se ter um grande nmero de testes unitrios passando
com sucesso, pode passar uma falsa sensao de segurana, resultando na implementa-
o de menos atividades de garantia de qualidade, como testes de integrao e testes de
conformidade.
importante ressaltar tambm que, esta tcnica no garante a obteno de nveis
aceitveis em certos aspectos do software final, como usabilidade e desempenho. Alm
disso, TDD no consegue mitigar riscos relacionados com a falta de requisitos ou com
requisitos erroneamente definidos.

Referncias
Astels, D. (2003). Test-Driven Development: A Practical Guide. Prentice Hall PTR.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison Wesley.
Beck, K. (2002). Test-Driven Development By Example. Addison Wesley.
Bellware, S. (2009). http://www.tvagile.com/2009/08/13/good-test-better-code-from-
unit-testing-to-behavior-driven-development/. Good Test, Better Code - From Unit
Testing to Behavior-Driven Development (10:40).
Fowler, M. (2006). Continuous integration.
Friedman, L. (2009). Quality - an agile point of view. TE: Testing Experience, Setem-
bro:16 17.
2
Segundo [Fowler 2006], integrao contnua uma pratica de desenvolvimento de software onde os
membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos
diariamente, podendo haver mltiplas integraes por dia. Cada integrao verificada por um build auto-
matizado (incluindo testes) para detectar erros de integrao o mais rpido possvel. Muitos times acham
que essa abordagem leva a uma significante reduo nos problemas de integrao e permite que um time
desenvolva um software coeso mais rapidamente.
Hawley, M. (2004). http://weblogs.asp.net/mhawley/archive/2004/04/15/114005.aspx.
TDD Research Findings.
James P. Womack, Daniel T. Jones, D. R. (1990). The machine that changed the world.
Koskela, L. (2008). Test Driven: Pratical TDD and Acceptance TDD for Java Developers.
Manning.
Langr, J. (2005). Agile Java Crafting Code with Test-Driven Development. Prentice Hall
PTR.
Lewis, W. E. (2004). Software Testing and Continuous Quality Improvement. Auerbach,
2 edition.
Schwaber, K. (2004). Agile Project Management with Scrum. Microsoft Press.
Tian, J. (2005). Software Quality Engineering: Testing, Quality Assurance, and Quantifi-
able Improvement. John Wiley & Sons.