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 development 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 mitigates or eliminates the occurrence of these situations. Finally, it highlights other important quality factors that the test-driven development does not resolve properly. Resumo. O presente artigo evidencia de que maneira as consequncias do emprego 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 desorganizado. Demonstramos como o emprego do desenvolvimento orientado a testes ameniza ou elimina a ocorrncia dessas situaes. Ao nal, 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 modernos. Este incremento em tamanho e complexidade acaba por causar consequncias nointencionais em termos de gerar problemas de qualidade [Tian 2005]. A alta complexidade e o amplo escopo dicultam 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 classes 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 reao contrria aos processos de desenvolvimento utilizados na poca, caracterizados como pesados, burocrticos, micro-gerenciados e com uma alta tendncia a se produzir documentos 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 software. 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 especcas 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 determina 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 signicado 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] identica 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. Enquanto o desenvolvedor espera que o sistema se comporte de certa maneira, o comportamento exibido diferente devido a defeitos inseridos na fase de codicao. 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 substancial de dados que ir requerer um esforo signicativo para serem reproduzidos (quando possvel). O segundo fator est ligado a problemas de usabilidade, onde um produto de difcil 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 insuciente para atender seus propsitos. O terceiro fator, funcionalidades do sistema que no so utilizadas, tambm representam um fator de desperdcio. Alm de inteis, retardam e dicultam o uso do sistema. Esta a forma de desperdcio que mais despende esforos para ser localizada e eliminada. 2.1.1. Vericao versus Validao Vericao provar que o produto atende corretamente os requisitos especicados em atividades prvias durante o ciclo de vida de desenvolvimento, j a validao checa que o
O termo lean foi cunhado ao nal 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).
1

sistema atende os requisitos do cliente ao nal 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 negocivel, ela deve ser xada como tima durante todo o ciclo de vida do software. Algumas equipes, na esperana de reduzir o prazo de entrega, sacricam temporariamente a qualidade interna na esperana de que a qualidade externa no sofrer um grande impacto. Esta estratgia muito tentadora em um cenrio em curto prazo. Porm, eventualmente problemas de qualidade interna o alcanaro e tornaro aquele software proibitivamente 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 errneas 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 organizacionais, 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 codicao 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, simplicidade, feedback, respeito e coragem. D nfase no trabalho em equipe, permitindo que os desenvolvedores respondam com conana 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 adequado 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 objetivo comum. [Schwaber 2004] arma que o Scrum baseia todas as suas prticas em uma estrutura 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 inspecionar 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 entregvel ao nal da iterao. O time deixado a ss para fazer seu melhor esforo pelo resto da iterao. Ao nal 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 simplicao das atividades de desenho de software. [Koskela 2008] resume a losoa do TDD em uma frase somente escreva cdigo para fazer um teste falho passar. [Astels 2003] dene 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-Codicao-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-Codicao-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 comparada ao ciclo Teste-Codicao-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-Codicao-Refatorao tambm pode ser chamado de ciclo Vermelho-Verde-Refatorao [Astels 2003]. O vermelho simboliza a fase inicial do ciclo 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. Renamos 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 decincias 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 modicaes 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 ca 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 probabilidade 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, armou que ainda no haviam estudos que demonstrassem cientcamente 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 Simplicado e Evolucionrio Escrevendo somente o necessrio para os testes e removendo toda a duplicao, voc automaticamente obtm um desenho que perfeitamente adaptado para os requisitos atuais e igualmente preparado para todas as futuras funcionalidades [Beck 2002]. Design simplicado reduz os custos porque ao escrever menos cdigo para atender os requisitos, menos cdigo existir para ser mantido no futuro. Design simplicado mais fcil de se construir, manter e entender. 3.2. Refatorao Os testes lhe do a conana de que grandes refatoraes no mudaro o comportamento do sistema, o que se conclui que, quanto maior a conana, 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 modicado. 3.3. Feedback Constante [Beck 2002], no ltimo captulo de sua publicao, arma que TDD o ajuda a dar ateno aos problemas certos na hora certa, de forma que o desenho do software ca mais limpo e com muito menos defeitos. O TDD faz com que o programador ganhe conana sobre seu cdigo com o passar do tempo, isto , medida que os testes vo se acumulando (e melhorando), ele ganha conana no comportamento do sistema. E ainda, medida que o desenho renado, 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 denida 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 permitem que o desenho possa ser modicado 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 especica 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 implementao 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 nal, como usabilidade e desempenho. Alm disso, TDD no consegue mitigar riscos relacionados com a falta de requisitos ou com requisitos erroneamente denidos.

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-fromunit-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, Setembro:16 17.
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 vericada por um build automatizado (incluindo testes) para detectar erros de integrao o mais rpido possvel. Muitos times acham que essa abordagem leva a uma signicante reduo nos problemas de integrao e permite que um time desenvolva um software coeso mais rapidamente.
2

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 Quantiable Improvement. John Wiley & Sons.