PONTIFCIA UNIVERSIDADE CATLICA DE MINAS GERAIS IEC - Instituto de Educao Continuada

UTILIZAO DE TDD EM PROJETOS DE SOFTWARE:

Estudo de Caso Acadmico

Bruno Amarante Couto Rezende

Belo Horizonte 2011

Bruno Amarante Couto Rezende

UTILIZAO DE TDD EM PROJETOS DE SOFTWARE:

Estudo de Caso Acadmico

Monografia apresentada ao Curso de PsGraduao em Engenharia de Software da Pontifcia Universidade Catlica de Minas Gerais, como requisito parcial para

obteno do ttulo de Especialista em Engenharia de Software.

Orientador: Prof. Pedro Alves de Oliveira

Belo Horizonte 2011

Bruno Amarante Couto Rezende

UTILIZAO DE TDD EM PROJETOS DE SOFTWARE:

Estudo de Caso Acadmico

Monografia apresentada ao Curso de PsGraduao em Engenharia de Software da Pontifcia Universidade Catlica de Minas Gerais, como requisito parcial para

obteno do ttulo de Especialista em Engenharia de Software.

__________________________________________ Pedro Alves de Oliveira (Orientador) PUC Minas

Belo Horizonte, 17 de outubro de 2011

 meus avs, Vincius e Elvira, que durante esta jornada foram escolhidos por Deus para alegrar a vida do cu.

AGRADECIMENTOS

Agradeo a Deus, fora constante nesta caminhada. A meus pais e minha irm pelo companheirismo e apoio irrestrito, meu porto seguro em todos os momentos. Tambm a minha namorada Laura pela pacincia e compreenso com os finais de semana perdidos. A todos os professores, em especial ao professor Pedro, pelos ensinamentos tcnicos e de vida que transmitiram e que possibilitaram a concluso deste curso. Aos amigos da turma 22, trilhamos o mesmo caminho, superamos os interminveis trabalhos e que, matria aps matria, conseguimos atingir nossos objetivos. Deixo um agradecimento especial aos amigos Geidivan, Raphael, Thiago, Augusto, Priscila, Regina, Wesley, Davidson, Rhuan, Karla e Ana Paula. A famlia da Repblica Quis trem hiem, vocs que so mais que amigos. Durante toda esta caminhada me ajudaram e suportaram. Sempre agradeo a Unipac Bom Despacho, a seus professores e a turma 2006/2009 de Sistemas de Informao que me abriram tantas portas, como esta aqui neste curso. Por fim, agradeo a Powerlogic Consultoria e Sistemas S.A., empresa que me possibilitou um crescimento profissional muito grande durante a realizao deste curso de ps-graduao.

If you cant write a test for what you are about to code, then you shouldnt even be thinking about coding

Dave Chaplin

RESUMO

Nesta monografia um estudo foi realizado sobre os processos de desenvolvimento de software e o papel destes na construo de aplicaes. O foco foi apresentar o Desenvolvimento Orientado a Teste (TDD), sendo, para isso, apresentadas as metodologias adotadas pela Engenharia de Software desde os processos lineares, com pesada documentao at os mtodos geis, dos quais o TDD originou-se. Essa tcnica de desenvolvimento que ao contrrio do que o nome leva a entender, no trata apenas de testes, mas abrange todo o processo de desenvolvimento de uma aplicao. Adotar TDD consiste em uma mudana no fluxo tradicional de desenvolvimento, traz os testes para os passos iniciais, sendo eles o suporte para o desenvolvimento. Por fim um projeto piloto foi desenvolvido na linguagem Java para avaliar o TDD, o qual possibilitou identificar pontos positivos e negativos da sua utilizao.

Palavras-chaves: Engenharia de Software, Desenvolvimento Orientado a Teste, Tcnicas de Desenvolvimento de Software

LISTA DE FIGURAS

FIGURA 1 Estratgia de Testes de Software ................................................... FIGURA 2 Fluxo bsico de um ciclo de TDD ....................................................

23 28

FIGURA 3 Prtica do XP ................................................... ............................... 30 FIGURA 4 Ciclo XP e a prtica TDD ................................................................. 31 FIGURA 5 Estria do Usurio Autorizar Doao ........................................... FIGURA 6 Arquitetura JUnit ................................................... .......................... FIGURA 7 Lista tarefas para desenvolvimento ................................................. FIGURA 8 Trecho de cdigo da classe de teste unitrio .................................. FIGURA 9 Trecho cdigo mtodos de validao de doao............................. 36 37 39 39 40

LISTA DE TABELAS E QUADROS

QUADRO 1 Comparao variaes de TDD ....................................................

32

LISTA DE ABREVIATURAS

API Application Programming Interface ATDD Acceptance Test Driven Development BDD Behaviour Driven Development IDE Ambiente Integrado para Desenvolvimento NDD Need-Driven Development RUP Processo Unificado Rational TDD Desenvolvimento Orientado a Testes XP eXtreme Programming

LISTA DE SIGLAS

IEEE Institute of Electrical and Electronic Engineers NIST National Institute of Standards and Technology

SUMRIO 1 INTRODUO ................................................................................................... 13 1.1 Conceito .......................................................................................................... 13 1.2 Problema ......................................................................................................... 14 1.3 Justificativa ..................................................................................................... 15 1.4 Objetivos ......................................................................................................... 16 1.4.1 Objetivo Geral ................................................................................................. 16 1.4.2 Objetivos Especficos .................................................................................... 16 1.5 Metodologia..................................................................................................... 16 1.6 Organizao do Trabalho ............................................................................... 17 2 DESENVOLVIMENTO ORIENTADO A TESTES ............................................... 18 2.1 Conceitos Gerais ........................................................................................... 18 2.1.1 A Engenharia de Software ............................................................................ 19 2.2 Mtodos geis na Engenharia de Software ................................................ 21 2.3 Testes de Software ........................................................................................ 23 2.4 Test Driven Development (TDD) ................................................................... 25 2.4.1 Implantando TDD ........................................................................................... 27 2.4.1.1 Tratando Dependncias entre Unidades ................................................... 29 2.4.2 Aplicao de TDD e eXtreme Programming ................................................ 29 2.4.3 Variaes de TDD .......................................................................................... 31 2.5 Heranas do TDD .......................................................................................... 32 2.5.1 Vantagens do TDD ......................................................................................... 33 2.5.2 Desvantagens do TDD .................................................................................. 34 3 PROJETO BASEADO EM TDD ......................................................................... 36 3.1 Descria do Projeto ..................................................................................... 36 3.2 O Ambiente de Desenvolvimento ................................................................. 37 3.3 Utilizao de TDD .......................................................................................... 38 3.4 Lies Aprendidas ........................................................................................ 41 4 CONSIDERAES FINAIS ............................................................................... 42 4.1 Trabalhos Futuros ......................................................................................... 43

13

1 INTRODUO

Construir aplicaes robustas e confiveis uma busca presente na indstria de software desde seu incio. Na tentativa de facilitar o alcance destes objetivos, modelos de desenvolvimento, como cascata e espiral surgiram. Porm, devido burocracia e rigidez dos processos, esses modelos no conseguiram atender plenamente s necessidades das empresas desenvolvedoras de software (Fowler, 2005). De acordo com Fowler (2005), este cenrio possibilitou que metodologias de desenvolvimento aparecessem. Estas metodologias so mais simples, objetivas e adaptativas, tornando possvel trabalhar e controlar requisitos imprecisos e indefinidos. So as chamadas metodologias geis, como por exemplo, eXtreme Programming (XP) e Scrum, que pregam o mnimo de documentao possvel no projeto e um constante feedback e realinhamento dos requisitos e objetivos do projeto. Junto a estas metodologias geis surgiram tcnicas que viabilizam uma agilidade mantendo-se controle e gerenciamento do projeto. Dentre estas, o desenvolvimento orientado a testes Test Driven Development (TDD) uma tcnica presente em muitas destas metodologias geis e ser o objeto de estudo desta monografia.

1.1 CONCEITO

TDD surge da tentativa das empresas de melhorar a qualidade das aplicaes construdas uma vez que para garantir espao no mercado de software, elas necessitam oferecer produtos com qualidade e, garantir isto, tem se tornado uma tarefa complexa e onerosa. Consiste de uma tcnica de desenvolvimento que vai de encontro ao modo tradicional de construo de software, onde os testes so executados aps a codificao para validao e verificao. TDD prega que os testes devem ser criados antes da codificao de maneira a aumentar e facilitar a compreenso da aplicao a ser construda.

14

Koskela (2007) define TDD como uma tcnica que se aplica ao desenvolvimento de software e no apenas aos testes. Mesmo tendo nos testes seu ncleo, ela utiliza estes para guiarem toda codificao e no apenas para validar o que foi construdo, possibilitando a criao de um cdigo limpo, testado e incremental. Marrero e Settle (2005) afirmam que o objetivo de TDD est na especificao, em compreender e definir o desenvolvimento da aplicao, alinhada ao mximo s funcionalidades definidas, e no na validao e verificao do que foi construdo. Essa tcnica baseada em iteraes nas quais so escritos testes para as funcionalidades especificadas, para ento se iniciar a codificao. O cdigo avaliado e refatorado o que garante um cdigo o mais limpo e compreensvel. Assim, a cada iterao o projeto vai sendo construdo de modo confivel, consistente e alinhado aos requisitos.

1.2 PROBLEMA

Segundo Santin (2006), comumente as empresas executam testes de validao e verificao no software desenvolvido para avaliar se o mesmo atende s especificaes e no possui erros no cdigo. Porm, mesmo utilizando desta tcnica, as aplicaes continuam a apresentar erros e falhas. Erros so responsveis por um aumento no tempo e no custo de projetos de software em todo o mundo. Segundo Borges (2006), existem estudos que demonstram como os erros so um fardo no desenvolvimento de software. Um destes estudos realizado em 2002 pelo NIST (National Institute of Standards and Technology) e pelo Departamento de Comrcio dos Estados Unidos mostrou que falhas em softwares custam cerca de 60 bilhes de dlares s empresas e ao governo norte americano por ano. Erros em aplicaes alm de ser um problema para os usurios finais representam tambm, para as empresas desenvolvedoras, um grande obstculo. As anlises destacadas deixam claro que um produto que apresenta falhas gera prejuzo financeiro, alm de abalar a confiana dos clientes e dificultar que as empresas se consolidem no mercado.

15

1.3 JUSTIFICATIVA

Estudos das tcnicas de desenvolvimento orientado a testes esto ganhando importncia devido ao seu foco em erros. Como mencionado na seo 1.2, erros em software apresentam um grande prejuzo e obstculo para as empresas. Oneram os prazos e custos de projetos e transmitem, para o mercado, uma imagem de desconfiana em relao empresa. Assim, TDD surge para buscar uma nova maneira de identificar erros e garantir uma construo mais confivel, consistente e robusta de aplicaes. Uma tcnica bem definida e estruturada para coordenar os projetos pode proporcionar s empresas de desenvolvimento de software uma economia considervel e aumentar a qualidade das aplicaes construdas. Neste cenrio, TDD tem se apresentado como boa alternativa para o gerenciamento de projetos de desenvolvimento, justamente por tentar identificar e corrigir erros logo no incio do projeto (Borges, 2006). A identificao e correo de falhas nas fases iniciais dos projetos so importantes, uma vez que os custos que estas acarretam crescem

exponencialmente com o transcorrer do tempo. Em um estudo realizado nos fins dos anos 1990, Viegas e McManus (2000) demonstram que a correo de um erro identificado durante a fase de especificao custa, em mdia, US$ 139,00. J se um erro for encontrado na fase de desenvolvimento, o valor sobe para US$ 7.000,00, caso a falha s seja descoberta e corrigida aps a implantao da aplicao o custo mdio passa a ser de US$ 14.000,00. TDD busca uma forma eficiente de identificar e corrigir falhas em um projeto de software, tornando-se uma tcnica til na busca de qualidade na construo de aplicaes. Porm como se trata de uma tcnica recente e que vai de encontro ao modelo tradicional de desenvolvimento necessrio que estudos sejam realizados a fim de definir a melhor maneira de utiliz-la nas empresas de forma correta e que traga os benefcios esperados.

16

1.4 OBJETIVOS

1.4.1 OBJETIVO GERAL

Descrever as vantagens da utilizao de uma abordagem de desenvolvimento orientado por testes, tanto de forma terica quanto aplicada a um projeto acadmico desenvolvido de acordo com essa metodologia.

1.4.2 OBJETIVOS ESPECFICOS

Os seguintes objetivos devem ser atingidos ao longo desta pesquisa, a fim de viabilizar o objetivo final: Abordar os conceitos, a aplicabilidade, as vantagens e desvantagens do TDD. Relacionar essa tcnica com as metodologias geis e as atividades envolvidas em um projeto de desenvolvimento guiado por testes. Apresentar a utilizao de TDD na forma de um estudo de caso baseado em um projeto desenvolvido segundo esta metodologia. Destacar ferramentas, tcnicas utilizadas e analisar os resultados e lies aprendidas no estudo de caso.

1.5 METODOLOGIA

Este trabalho pode ser visto sob dois aspectos: terico e aplicado. O primeiro consiste de um estudo baseado em uma abordagem dedutiva e qualitativa que apresenta os conceitos, vantagens, desvantagens e atividades empregadas em um projeto orientado a testes.

17

J o segundo aspecto baseado num projeto desenvolvido segundo TDD. Ser apresentado um projeto acadmico, desde a fase inicial, na qual a tcnica foi introduzida, o desenvolvimento de uma funcionalidade da aplicao seguindo esta metodologia e as ferramentas utilizadas para a construo dos testes. Alm disto, relatar a adequao tcnica, os resultados encontrados e as lies aprendidas durante este projeto. Mesmo com a crescente utilizao, ainda difcil encontrar projetos construdos segundo TDD, principalmente por mudar o ciclo tradicional de desenvolvimento. Sendo assim, o projeto base do estudo de caso deste trabalho ser um projeto acadmico com emprego de TDD, que pode ser tomado como referncia para trabalhos futuros. Os detalhes do projeto e os resultados obtidos esto descritos nos captulos 3 e 4.

1.6 ORGANIZAO DO TRABALHO

Este o trabalho encontra-se dividido em uma parte terica discorrendo sobre TDD e outra prtica, analisando sua utilizao. Cada um destes aspectos tratado em um captulo, sendo que o ltimo captulo traz uma anlise dos resultados encontrados durante a construo deste trabalho. O Captulo 2 apresenta uma conceituao sobre desenvolvimento de software, metodologias geis e, principalmente, sobre o desenvolvimento orientado a testes. O foco est em mostrar a aplicabilidade de TDD e suas vantagens e desvantagens em relao s metodologias tradicionais de desenvolvimento. O Captulo 3 traz um estudo de caso baseado em projeto que foi desenvolvido utilizando TDD. Descreve o projeto e apresenta como a tcnica foi aplicada e conclui com as lies aprendidas. Por fim o Captulo 4 mostra as concluses desta monografia e quais as dificuldades encontradas durante sua construo. Finalizando apresenta alguns temas para trabalhos futuros.

18

DESENVOLVIMENTO ORIENTADO A TESTES

O nome atribudo - Desenvolvimento Orientado a Testes (Test Driven Development) induz a uma tcnica relacionada apenas a testes, porm trata-se de uma tcnica de projeto. TDD traz uma nova viso do processo de desenvolvimento de software. O surgimento dessa tcnica foi baseado em estudos relacionados Engenharia de Software, testes, metodologias de desenvolvimento e mtodos geis. Este captulo apresenta um estudo sobre estes conceitos, sempre direcionando para a influncia destes sobre o TDD (Santos, 2010).

2.1 CONCEITOS GERAIS

TDD surge como uma soluo no processo de construo de software, mas as primeiras idias de buscar uma estruturao do processo de desenvolvimento de software apareceram na dcada de 1970, quando aplicaes eram construdas de forma desorganizada e sem planejamento. Este cenrio conduzia a atrasos nos projetos, falta de documentao e, principalmente, falta de qualidades dos produtos. Mesmo projetos concludos no prazo tinham grande chance de no atender as necessidades dos clientes, o que gerava prejuzos tanto a indstria do software quando aos clientes (Pressman, 2006). Alm disso, o desenvolvimento de hardware mais potente e barato, difundiu o uso de computadores e trouxe a exigncia para que os softwares tambm se desenvolvessem com qualidade. Neste momento surgiram as primeiras

metodologias de desenvolvimento de software. Elas propunham uma diviso de todo o processo de construo em fases definidas, levando em consideraes as caractersticas de cada projeto, como tempo, recursos e plataforma (Vasconcelos et al, 2006). Este ambiente de mudana, planejamento e estruturao do software tornou propcio o surgimento de uma disciplina, que at os dias atuais, influencia a construo de softwares, possibilitando a construo de aplicaes mais confiveis, robustas e de uma maneira mais eficiente, a Engenharia de Software.

19

2.1.1 A ENGENHARIA DE SOFTWARE

Sommerville (2006) afirma que Engenharia de Software uma disciplina que trata de todos os aspectos da produo de software, desde a especificao at a manuteno do sistema. IEEE (1993) define, de forma abrangente, como a aplicao de uma abordagem sistemtica, disciplinada e qualificvel, para o desenvolvimento, operao e manuteno do software, isto , a aplicao da engenharia ao software. Pressman (2006) destaca que mesmo tendo o aspecto sistemtico e disciplinado essencial que a Engenharia de Software seja gil e adaptvel as novas exigncias do mercado. Tambm de acordo com o autor, qualquer engenharia baseada em camadas que se complementam, tornando possvel criar um processo focado na qualidade dos produtos. Na Engenharia de Software no diferente, o processo define como os mtodos sero executados. Assim, desenvolveu-se a base para o controle gerencial dos projetos. O desenvolvimento orientado a testes tornou-se popular com a utilizao das metodologias geis, no incio dos anos 2000, em um contexto consistente que possibilitou o crescimento da sua utilizao. Porm, at o aparecimento deste tipo de desenvolvimento, a Engenharia de Software props vrios modelos de desenvolvimento, sempre buscando atender demanda da indstria de software e seus clientes. Os primeiros modelos propostos surgiram em um contexto baseado apenas em mainframes e terminais burros, bem diferente das necessidades atuais, como portabilidade e mudana constante de requisitos. Isto permitia que os softwares fossem planejados e especificados antes de serem construdos. Este tipo de construo ficou conhecido como clssico, seqencial ou cascata (Soares, 2004). Este modelo trabalha com etapas pr-definidas e seqenciais, onde o fim de uma corresponde ao inicio da prxima. As etapas que um projeto percorre neste modelo so: definio de requisitos, projeto do software, implementao, testes, operao e manuteno. A falta de flexibilidade e adaptabilidade, alm da pesada documentao, so os principais problemas desta abordagem, dificultando possveis alteraes e correes nos requisitos de um projeto. Mesmo com estas dificuldades,

20

esse modelo de ciclo de vida foi muito utilizado at o incio da dcada de 1990 e serviu como base para outros tipos de modelagem (Pressman 2006). A fim de tentar corresponder s necessidades das empresas de

desenvolvimento, outros modelos surgiram no mercado, levando em considerao que as aplicaes tendem a evoluir durante a sua construo e que esta evoluo gera novas funcionalidades, aumentando e alterando as especificaes iniciais. Neste cenrio, os chamados modelos evolucionrios ganharam maior espao entre as empresas. De acordo com Sommerville (2006) a abordagem evolucionria se destaca por sua interatividade, o que permite o lanamento de vrias verses da aplicao durante seu desenvolvimento, cada uma com novas funcionalidades. Isto permite que o cliente sempre veja o resultado do projeto e proponha correes e alteraes durante o desenvolvimento do projeto. De acordo com Pressman (2006) o modelo incremental foi o primeiro a adotar esta abordagem. Porm, limitava-se a dividir o modelo em cascata em iteraes, sendo que cada iterao deveria passar por todas suas etapas. A partir deste surgiu o modelo espiral que alm de manter a sistemtica e dividir em iteraes trouxe mais iteratividade para o processo e uma caracterstica que o diferenciava dos demais, o acompanhamento de todo o ciclo de vida do software. Sommerville (2006) enfatiza que o modelo em espiral pode ser considerado o mais realstico, sendo base para a metodologia mais comumente utilizada no mercado - o Processo Unificado Rational (RUP). Elas tm como caractersticas principais a previsibilidade dos requisitos do sistema e a diviso em etapas ou fases bem definidas que englobam atividades como anlise, modelagem, construo e testes. Mesmo sendo utilizadas amplamente, estas metodologias so criticadas devido a sua grande carga de documentao, o que acaba onerando o projeto. Em meio a este contexto de metodologias pesadas e projetos fracassando, um grupo de profissionais se reuniu em 2001 na busca de um modelo de desenvolvimento que trouxesse melhores resultados. Porm concluram que era um processo muito complexo para ser definido e, atravs de um documento conhecido como Manifesto gil, propuseram alguns princpios essenciais para se obter bons resultados no desenvolvimento de software. Assim, as metodologias geis surgiram e junto delas tcnicas que possibilitam uma nova maneira de construir software (Bassi, 2008).

21

Este estudo sobre a Engenharia de Software, seus processos e modelos, buscou demonstrar o contexto consistente para o aparecimento das metodologias geis e suas tcnicas. Dentro destas, o desenvolvimento orientado a testes surge como uma mudana na forma tradicional de se construir software. O tpico seguinte apresenta os mtodos e sua aplicabilidade.

2.2 MTODOS AGIS NA ENGENHARIA DE SOFTWARE

De acordo com Almeida (2007) metodologias geis possibilitam alteraes constantes no cdigo de um software, acompanhando as alteraes de requisitos, sem prejudicar sua qualidade. Os objetivos destes mtodos diminuir

documentao e burocracia, evitando os problemas enfrentados com os mtodos tradicionais ou pesados. E justamente neste contexto que elas surgem, para melhorar a qualidade dos projetos desenvolvidos. Um estudo realizado por profissionais da rea de engenharia de software no inicio de 2001, constatou que mesmo com os vrios benefcios trazidos pelos modelos tradicionais de desenvolvimento, alguns riscos e perdas dos projetos s poderiam ser minimizados com pensamento e atitudes diferentes, como afirma Almeida (2007). Ento propuseram um documento o que ficou conhecido como o marco inicial dos mtodos geis - o Manifesto gil. O Manifesto gil apresenta as concluses, propsitos e princpios que devem nortear os modelos que se basearem nesta metodologia. Todas as idias apresentadas so uma tentativa de reencontrar o equilbrio entre produtividade, sucesso e qualidade dos projetos de software. Os princpios apresentados neste manifesto por Beck et al (2001) demonstram claramente o que foi proposto e o que esperado de um modelo gil:
Nossa prioridade mais alta satisfazer o cliente atravs de entregas contnuas e antecipadas de software vlido. Mudanas nos requisitos so bem-vindas, mesmo as que chegam tarde no desenvolvimento. Processos geis asseguram a mudana como uma vantagem competitiva do cliente. Entregar software produtivo freqentemente, de algumas semanas a alguns meses, de preferncia os tempos mais curtos.

22

Pessoal de negcio e desenvolvedores trabalham juntos diariamente durante o projeto. Criar projetos em torno de indivduos motivados, proporcionar o ambiente e suporte que eles necessitam e confiar que eles faro o servio. O mtodo mais eficiente e efetivo para transmitir informaes entre e para a equipe de desenvolvimento converso cara a cara. Software produtivo a medida primria do progresso. Processos geis promovem um desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. Ateno contnua excelncia tcnica e boa soluo melhoram a agilidade. Simplicidade a arte de maximizar a quantidade de trabalho no feita essencial. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva e ento sintoniza e ajusta seu comportamento de forma apropriada. Beck, et al (2001)

Esses princpios evidenciam que metodologias geis necessitam de um gerenciamento colaborativo e de uma equipe baseada na comunicao e na transparncia. Outro ponto chave so as iteraes. O projeto deve ser dividido em ciclos pequenos, com participao direta do cliente e no fim de cada iterao um produto entregue a este (Bassi, 2008). Quanto aos testes, ao contrrio das metodologias tradicionais, onde estes so uma atividade independente e executada aps a implementao, nas metodologias geis a preferncia por testes unitrios, construdos e executados junto implementao. Assim, a tcnica de desenvolvimento orientado a teste se apresenta como uma soluo pertinente para projetos geis, garantindo cobertura de testes e, conseqentemente, qualidade. O tpico 2.3 trata com mais detalhes de testes de software e o 2.4 apresenta o desenvolvimento orientado a testes. Diante disso, as metodologias geis no surgiram para acabar com a documentao, mas para buscar um equilbrio desta com o desenvolvimento de projetos de software. O Scrum e o XP so bons exemplos de modelos que buscam uma agilidade gerenciada e uma participao efetiva de todos os envolvidos no projeto. O maior benefcio com a utilizao destes modelos a facilidade de adaptao do projeto s mudanas que sempre surgem.

23

2.3 TESTES DE SOFTWARE

Independentemente da metodologia adotada em um projeto de software essencial que testes sejam realizados para garantir a qualidade do produto construdo. De acordo com Pressman (2006), um teste compreende um conjunto de atividades a serem planejadas e executadas sistematicamente durante o projeto. Da a importncia de se definir uma estratgia de teste adaptativa e flexvel, capaz de traar um roteiro que atenda ao projeto. Um roteiro contempla os nveis em que os testes sero executados, bem como as estratgias e mtodos a serem adotados. Para Pressman (2006) os nveis de testes devem seguir a espiral representada na Figura 1, do centro para fora, e assim, cobrir todo o projeto.

Figura 1: Estratgia de Testes de Software Fonte: Pressman, 2006 Os testes iniciam em um nvel mais baixo at cobrir todo o sistema. O ciclo se inicia com o teste de unidade, que se concentram em pequenas unidades, como mdulos, classes ou mesmo um mtodo e normalmente so criados pelos prprios desenvolvedores. Passam pelos testes de integrao foca na arquitetura da aplicao e na integrao entre as unidades j testadas. Com uma parcela j desenvolvida comea o teste de validao, que avalia se o que foi construdo esta atende aos requisitos definidos na anlise. Por fim o teste de sistema verifica a aplicao como um todo, sendo realizados testes de desempenho, usabilidade e segurana (Pressman, 2006).

24

Os mtodos mais utilizados para a realizao so os testes caixa-branca, caixa-preta e caixa-cinza. Cada um desses possui uma caracterstica que se adqua demanda do projeto. Testes caixa-branca baseiam-se na estrutura interna do objeto a ser testado, buscando a cobertura da maior quantidade de caminhos possveis que um fluxo possa percorrer neste. De forma mais simples, esses testes examinam detalhadamente o cdigo fonte da aplicao. Hunt e Thomas (2003) afirmam que esse mtodo utilizado para testes de unidade, uma vez que conhecer o cdigo fonte essencial para estes testes. Testes caixa preta so conhecidos tambm como teste de entrada e sada, uma vez que no analisam o comportamento interno do objeto testado, mas sua reao diante de determinadas entradas. Neste mtodo importante definir uma lista variada de entrada, buscando contemplar o mximo de alternativas possveis, e analisar se as sadas providas esto de acordo com o esperado. Sua utilizao comum em testes de validao e de sistemas. Existe tambm o chamado teste caixa cinza que mescla os dois mtodos expostos anteriormente, sendo considerado um teste funcional e estrutural, uma vez que foca nas funcionalidades pautando-se pela especificao. Nesse mtodo a comunicao entre tester e desenvolvedor essencial, facilitando a identificao de funcionalidades que se repetem na aplicao o que permite que esta seja testada apenas uma vez (Lewis, 2000). A correta definio dos dados para a execuo de mtodos de teste uma atividade que garante a qualidade dos testes executados e, conseqentemente do produto avaliado. Para facilitar, Ammann (2008) apresenta uma srie de estratgias a serem seguidas: Parties em classes de equivalncia: tomando como base o domnio de entradas vlidas, os valores so divididos em classes que representam determinada situao e para cada uma destas um conjunto representativo de valores definido para a execuo dos testes. Anlise de valores de fronteira: funciona como um complemento a estratgia anterior, tratando os valores de fronteira das classes de equivalncia. Valores de fronteira so os limites das classes e os valores mais prximos a estes.

25

Grafo de causa-efeito: a base so as funcionalidades a serem testadas, sendo definidas as aes (causas) e as reaes esperadas (efeitos). Ambas so relacionadas em um grafo e o teste ento executado.

Cobertura de lgica: avalia todas as instrues do objeto, podendo desdobrar-se em uma cobertura de decises sendo realizada avaliandose cada condies de todas as decises da aplicao.

Seleo aleatria de dados: normalmente utiliza-se em conjunto com outras estratgias e busca-se avaliar casos no definidos nos testes, uma vez que realiza os testes com valores no planejados.

Testes de regresso: trata-se de um conjunto de testes realizados aps alguma modificao efetuada em um artefato. Possibilitam a identificao de falhas em outros artefatos alm do modificado.

O desenvolvimento orientado a testes exige um conhecimento sobre tcnicas, mtodos e estratgias para verificao e validao de software. Este tpico apresentou informaes bsicas sobre estes processos, cabe a equipe definir a melhor forma de execut-los. Os testes de unidade so base do TDD, por isso, sero tratados com maiores detalhes na prxima sesso, que trata de Test Driven Development (TDD).

2.4 TEST DRIVEN DEVELOPMENT (TDD)

Os tpicos anteriores apresentaram a histria e o contexto nos quais o desenvolvimento orientado a testes surgiu. Esta seo detalha essa tcnica, suas caractersticas, vantagens e desvantagens. O desenvolvimento orientado a teste ou simplesmente TDD uma tcnica de desenvolvimento de software e, mesmo tendo nos testes seu ncleo, sua influncia no se limita apenas a esta fase. Gold, Hammel e Snyder (2004) afirmam que TDD no trata de testes, e sim, de como utiliz-los na construo de software. Baseandose em TDD a construo tende a ser simples e incremental, aumentando a qualidade e simplificando todo o processo de desenvolvimento.

26

Essa tcnica prope uma mudana na seqncia convencional de desenvolvimento planejar, projetar, implementar e testar e coloca os testes como a atividade inicial do processo, sendo a codificao baseada nos testes definidos inicialmente. Antes de iniciar o desenvolvimento preciso dividir o projeto em pequenas iteraes, para facilitar a definio do que ser construdo em cada etapa e, conseqentemente, a criao dos testes. Um projeto em TDD inicia-se com a criao de testes que definiro o comportamento de determinadas funcionalidades da aplicao e estes balizam as demais fases do desenvolvimento. Escrever testes ajuda a compreender melhor o domnio da aplicao e acaba por melhorar o desempenho dos desenvolvedores. Porm ao escrever os testes importante que se mantenha o foco em como testar uma funcionalidade e no a implementao do cdigo, para que eles possam realmente conduzir o desenvolvimento (Gold, Hammel e Snyder, 2004). Alguns autores, como Astels (2003), definem estes testes como testes de programador, afinal eles sero a base a ser seguida por estes. Os testes de unidade, tambm executados por programadores e muito utilizados em TDD, so utilizados para verificar a implementao, o cdigo de uma unidade (classe, funcionalidade ou mdulo). Conseguir estabelecer uma boa integrao entre testes de desenvolvedor (guia) e testes de unidade (valida) uma das chaves para o sucesso do TDD. Para sua implantao necessrio que haja uma mudana de cultura, uma adaptao por parte da empresa e da equipe de desenvolvimento. Desenvolvedores passam a ter maior domnio do negcio e executam testes e a empresa precisa acreditar que o aumento no tempo de desenvolvimento ser compensado com uma maior qualidade do produto. Assim, Astels (2003) mostra que antes de compreender o funcionamento de TDD importante enxerg-lo como uma tcnica de projeto software onde: nenhum cdigo construdo sem que haja testes associados a ele; testes so definidos antes da implementao e determinam o que ser construdo; mantido um conjunto de testes do programador, executados

rotineiramente.

27

2.4.1 IMPLANTANDO TDD

Um projeto desenvolvido orientado a testes deve ser construdo em pequenas iteraes. Isto evita que a aplicao se afaste de seu comportamento funcional e torna o projeto contnuo, gradual e verificvel. Assim, tambm, os desenvolvedores lidam com menos complexidade e focam em partes especficas da aplicao (Koskela, 2007). Inicialmente escrevem-se os testes e, baseados nestes a implementao e depois uma refatorao no cdigo realizada. Este o processo bsico de um ciclo, uma iterao do TDD. Koskela (2007) afirma que o ncleo do TDD est em teste, codifique e refatore. Com a utilizao de ferramentas da famlia xUnit pode ser considerado como vermelho, verde, refatore, onde vermelho seriam os testes que falham, verde para testes implementados corretamente e, por fim, a refatorao. Beck (2010) lista os seguintes passos para a implantao de TDD num ciclo de desenvolvimento: Escrever o teste para a funcionalidade a ser construda; Executar o teste e verificar se este falha; Implementar o cdigo que atenda ao teste; Executar todos os testes e verificar se passam; Por fim, melhorar o cdigo (refatorar).

Beck (2010) define esses passos da seguinte forma: para se escrever os testes preciso decompor um caso de uso, ou uma estria do usurio em vrias funcionalidades ou comportamento e definir os testes para esta menor unidade decomposta. importante que um teste definido seja independente de outros testes. Ao fim de um mdulo da aplicao ou de um conjunto de funcionalidades relacionadas aceitvel que se agrupe os testes (test suites) para facilitar a execuo dos mesmos. O segundo passo consiste em verificar se o teste definido vlido sintaticamente, ou seja, que ele ser executado. Neste passo ele deve falhar, uma vez que no existe cdigo implementando-o, apenas sua definio. Passo trs a

28

implementao bsica do cdigo, o desenvolvedor deve criar um cdigo que apenas faa o teste passar. A execuo dos testes vem para garantir que o cdigo implementado satisfaz o definido nos testes e no introduz erros na aplicao. Nesta fase o uso de frameworks de testes unitrios muito comum. Por fim vem a refatorao do cdigo. Gold, Hammel e Snyder (2004) definem refatorao como o processo de mudar o cdigo, com o nico objetivo de melhorar sua estrutura interna, sem mudar seu funcionamento. Nesse passo, por exemplo, so retirados cdigos duplicados, melhorada a legibilidade e comentrios so inseridos. A refatorao e os testes unitrios so bases do TDD, da a importncia de compreender estas duas tcnicas e saber aplic-las com eficincia. Esses passos representam o fluxo bsico de um ciclo em TDD. Com testes definidos a partir das funcionalidades o cdigo implementado, testado e refatorado. A figura 2 representa este fluxo atravs de um diagrama onde fica claro como os testes so sempre executados.

Figura 2: Fluxo bsico de um ciclo de TDD. Fonte: Elaborado pelo autor.

29

2.4.1.1 TRATANDO DEPENDNCIAS ENTRE UNIDADES

Uma questo sempre presente na implementao de TDD como tratar as dependncias entre as unidades a serem testadas. Existem dois modelos para tratar esta questo: o clssico e o mockist. O modelo clssico adota a utilizao das dependncias reais das unidades a serem testadas, por isso preciso que as dependncias estejam acessveis e, que toda a hierarquia de dependncia, seja instanciada para a execuo do teste. Os problemas deste modelo esto em instanciar todas as dependncias e detectar onde um possvel erro acontece, uma vez que o erro pode estar em qualquer unidade instanciada. Porm, o uso de dependncias reais torna os testes mais completos, porque testam tambm a integrao entre as unidades (Fowler, 2007). J o modelo mockist surgiu no contexto das metodologias geis para facilitar a execuo dos testes, garantindo a validao, exclusivamente, da unidade que est sendo testada. As dependncias so representadas por objetos mocks, que simulam outros objetos, atravs de uma interface pblica igual a das unidades originais. As vantagens esto em garantir a validao de uma unidade e facilitar a execuo dos testes, abstraindo-se as dependncias em unidades simples e criadas apenas para os testes. Em contrapartida perigoso que se criem testes em excesso e demasiadamente criteriosos devido facilidade de criao de testes (Fowler, 2007). Na implantao de TDD importante definir uma estratgia equilibrada para tratar as dependncias de modo que os testes no se tornem quebradios testes que falham ao se realizar uma alterao no cdigo e nem criteriosos totalmente dependentes das unidades reais.

2.4.2 APLICAO DE TDD E EXTREME PROGRAMMING

Desenvolvimento orientado a testes consiste de uma tcnica que deve ser empregada em um ambiente de desenvolvimento gil. Algumas metodologias geis vm sendo muito utilizadas por empresas, dentre as quais, o eXtreme Programming

30

ou simplesmente XP a de maior popularidade, alm de ter sido uma das percussoras do TDD (Astels, Miller e Novak, 2002). XP foi criada por Kent Beck em 1996. Trata-se de uma metodologia gil, na qual s se constri o que tenha valor para o cliente. Ela ganhou espao por se adaptar bem a requisitos vagos e mutveis, mas j possvel encontrar bons resultados desta prtica em projetos mais estveis e definidos (Beck e Andres, 2004). A relao de XP com TDD bem estreita. TDD pode ser considerado uma das tcnicas mais importantes e consistentes do XP, alm de compartilharem caractersticas comuns como pequenas iteraes, projeto simples e refatorao. Alm destas prticas, o XP trabalha com vrias outras como: jogo do planejamento, metforas, programao em pares, integrao contnua e mudanas incrementais. A figura 4 destaca o papel central do TDD nesta metodologia (Beck e Andres, 2004).

Figura 3: Prtica do XP. Fonte: Adaptado de O que eXtreme Programming, Ron Jeffries, 2001. Alm das prticas acima representadas o XP trabalha com valores que devem ser considerados na sua implementao: simplicidade, comunicao, coragem e rpido feedback. Estes valores so pontos chaves para se aplicar as prticas e conseguir bons resultados com essa metodologia (Manhes, 2004). A figura 4 apresenta um exemplo de implementao do XP baseada em estrias do usurio. Nessa implementao cada iterao tem seu escopo definido de acordo com as estrias, que so divididas em tarefas que, finalmente, so

31

implementadas utilizando TDD. No intuito deste trabalho detalhar o XP, suas prticas e valores, mas apenas destacar o uso de TDD em conjunto com essa metodologia.

Figura 4: Ciclo XP e a prtica TDD Fonte: Elaborado pelo autor.

2.4.3 VARIAES DE TDD

O desenvolvimento orientado a testes deu origem a outras tcnicas de desenvolvimento, algumas que estendem seu uso e outras que o particulariza a determinas situaes. A seguir sero apresentadas as mais destacadas variaes de TDD: Behaviour Driven Development (BDD): amplia o foco do TDD para o comportamento da aplicao, assim, no so os testes que guiam o desenvolvimento e sim especificaes que descrevem o comportamento de determinada funcionalidade. O processo idntico ao do TDD a grande diferena est na forma e no foco da especificao que conduz o desenvolvimento (Astels, 2006).

32

Acceptance Test Driven Development (ATDD): estende o uso de TDD para os testes de aceitao. Seu foco est em produzir aplicaes coerentes com as necessidades dos clientes. Nesta tcnica os testes de aceitao devem ser definidos no incio de cada iterao, muito parecido com TDD, mas ao invs de tratar do nvel de testes de unidades, trata de testes de comportamento da aplicao. Pode-se considerar que ATDD refere-se a qualidade externa, aos comportamentos do cdigo, enquanto TDD busca garantir a qualidade interna, lgica do cdigo (Koskela, 2007). Need-Driven Development (NDD): uma implementao particular de TDD que foca em garantir a qualidade de unidade a ser testada e utilize unidades mocks para representar as dependncias desta. Esta tcnica segue o processo do TDD facilitando a definio de responsabilidades das unidades, uma vez que toda responsabilidade externa a unidade que est sendo testada externalizada em um mock que futuramente se tornar uma unidade real da aplicao. O quadro 1 apresenta um resumo comparativo entre TDD e outras tcnicas destacadas. A utilizao de uma dessas tcnicas no exclui o uso de outras e possvel notar o uso de TDD presente nelas.

BDD Uso do TDD Foco Avalia Amplia Comportamento Qualidade da aplicao

ATDD Estende Testes de Aceitao Conformidade com necessidades do cliente

NDD Particulariza Dependncias (mocks) e responsabilidades Qualidade de uma nica unidade

Quadro 1: Comparao variaes de TDD. Fonte: Elaborado pelo autor.

2.5 HERANAS DO TDD

O uso de TDD verifica, constantemente, se a implementao funciona como definido, trazendo mais segurana e confiabilidade a todos os envolvidos no projeto. Alm de validar o cdigo, TDD auxilia na validao do design da aplicao. Como a construo guiada por testes unitrios, as classes tm restrio de

33

responsabilidades, so altamente coesas, e resolvem suas dependncias de forma simples, permitindo que sejam testadas isolada e facilmente, isto torna o projeto de baixo acoplamento (Silveira e Aniche, 2011). Silveira e Aniche (2011) afirmam que, para se conseguir baixo acoplamento e alta coeso, os desenvolvedores so levados a tomar decises de design mesmo antes de iniciar a implementao, quando esto definindo os testes que iro guiar a construo. importante saber aplicar padres de projeto e definir os relacionamentos e responsabilidades de cada unidade. Assim, possvel que o TDD deixe um bom legado para o projeto.

2.5.1 VANTAGENS DO TDD

Alm dos benefcios que o TDD traz para o design do projeto, Santin (2006) destaca, tambm, as seguintes vantagens da sua utilizao: Processo de desenvolvimento simples e incremental: a simplicidade est no fato do desenvolvedor focalizar apenas na unidade que est construindo, no se preocupando com regras e questes maiores do projeto. A construo incremental apresenta resultados mais rapidamente e permite que correes e alteraes sejam menos impactantes. Cdigo automaticamente testvel: como o cdigo construdo sobre testes de unidade, ele testado automaticamente testado durante o

desenvolvimento. Testes constantes: a cada alterao no cdigo todos os testes definidos so executados novamente, tonando imediata a identificao de possveis falhas introduzidas por estas mudanas, so os chamados testes de regresso e garantem que a cada iterao o sistema estar funcionando corretamente. Melhor compreenso dos requisitos: escrever os testes unitrios que guiaro o desenvolvimento permite, aos desenvolvedores, melhor

entendimento do domnio da aplicao. Os comportamentos esperados so detalhados de maneira concreta nos testes (Gold, Hammel e Snyder, 2004).

34

Evita centralizao de conhecimento: os testes unitrios tornam-se um repositrio de requisitos, permitindo que qualquer desenvolvedor consiga compreender os comportamentos esperados da aplicao. Para empresas muito interessante uma vez que evita que todo o conhecimento de um projeto esteja apenas na cabea de algumas pessoas. Aumento da cobertura de teste: como o princpio bsico do TDD escrever testes para, ento codificar, o percentual de cdigo com teste associado aumenta consideravelmente (Astels, 2003). Estas vantagens justificam o uso de TDD, uma vez que traz melhorias tanto para a equipe como para a empresa. Proporcionando maior qualidade ao projeto, menos erros e maior compreenso dos envolvidos.

2.5.2 DESVANTAGENS DO TDD

Para Andrade et al (2011) a maior desvantagem na implantao de TDD est na mudana de cultura pela qual a equipe de desenvolvimento e a empresa tm de passar. Os desenvolvedores precisam mudar sua mentalidade para a necessidade e importncia dos testes enquanto a empresa deve entender que o tempo gasto na definio dos testes no desperdcio, mas um investimento em qualidade. Outros fatores negativos so perceptveis no uso de TDD, na literatura os mais destacados so: Definies de testes no so isentas de erros: como o prprio desenvolvedor que escreve os testes, possvel que erros conceituais estejam presentes nestas definies. Manuteno dos testes: alm de manter o cdigo, preciso que os testes j escritos passem por manutenes, conforme a aplicao passar por alteraes. Falta de documentao: por sua origem gil, TDD no gera documentao formal como no modelo convencional, trabalha com a definio dos testes como um repositrio de requerimentos. A documentao tida em muitos projetos como parte do contrato e acordo entre cliente e empresa, nestes

35

casos, seria necessrio adaptar o processo o que em termos econmicos e de tempo no vivel. Limitao de domnio da aplicao: em determinados contextos o uso de TDD no vivel, como em projetos com componentes distribudos e interfaces grficas. Projetos nos quais atuem mais de uma empresa tambm tm o uso de TDD comprometido, principalmente porque o contato entre gestores, cliente e desenvolvedores torna-se complicado e demorado (Beck, 2010). Limitao financeira e de tempo: TDD aumenta o tempo de

desenvolvimento e, conseqentemente, os custos, por isso projetos onde existam este tipo de limitao no aconselhvel o uso desta tcnica.

36

PROJETO BASEADO EM TDD

O captulo anterior apresentou conceitos sobre TDD, seus princpios, mtodos e forma de implantao. Neste captulo desenvolvido um estudo de caso abordando um projeto piloto que utiliza esta tcnica. A fim de melhor compreend-la e identificar vantagens e desvantagens. A opo por desenvolver um projeto piloto acadmico decorreu de limitaes no acesso a um projeto comercial, que seria o objeto de estudo inicial. O desenvolvimento deste projeto est focado nas prticas definidas pelo TDD. Porm, para utilizar essa tcnica necessrio definir uma metodologia que a englobe. Neste caso so utilizadas algumas prticas de XP pequenas iteraes, estrias de usurio e definio de tarefas capazes de sustentarem a construo de uma aplicao com TDD.

3.1 DESCRIO DO PROJETO

O projeto piloto consiste de uma aplicao hipottica para uma associao de doao de sangue que deseja garantir mais segurana e rapidez nas doaes. Devido s restries de equipe e tempo ser desenvolvida uma nica iterao que compreender a estria do usurio apresentada na Figura 5.

Figura 5: Estria do Usurio Autorizar Doao Fonte: Elaborado pelo autor.

37

A partir dessa estria, definida por um cliente hipottico, foi construda uma aplicao em Java que atende a estes requisitos e que garante maior segurana para as doaes. A aplicao recupera informaes de um doador j cadastrado e executa as validaes definidas na estria de usurio definida acima e ento libera, ou no, o prosseguimento da doao.

3.2 O AMBIENTE DE DESENVOLVIMENTO

A aplicao foi desenvolvida sobre a plataforma Java SE, uma vez que este sistema tende a ser acessado em mquinas locais da associao. A IDE Eclipse Galileo foi utilizada para proporcionar maior produtividade na construo e simplificar a configurao e uso do JUnit ferramenta de testes unitrios que conduzir o desenvolvimento e tambm por se integrar facilmente com o banco de dados. Como o foco TDD, a ferramenta de testes unitrios merece destaque. JUnit uma sute de testes voltada para testar uma classe (unidade) ou uma funcionalidade especfica da aplicao. Foi desenvolvida com a linguagem Java e possui uma interface grfica simples que facilita a execuo dos testes e trabalha com uma das bases do TDD manter a barra de execuo dos testes unitrios verde garante um cdigo limpo (RAINSBERGER, 2008).

Figura 6: Arquitetura JUnit. Fonte: Medeiros, 2006. _____________

1 IDE uma aplicao que rene ferramentas e caractersticas que apiam o desenvolvimento de software, possibilitando maior produtividade dos desenvolvedores.

38

JUnit possui uma arquitetura que facilita a criao das classes de testes, como pode ser visto na Figura 6. Cabe ao desenvolvedor criar os mtodos para validar as funcionalidades da aplicao reutilizando esta arquitetura e tratando os valores esperados e os recebidos em cada operao com os assertivas, mtodos como assertEquals, assertNull, assertFalse, assertTrue e outros, que retornam se uma operao retornou o valor esperado (Medeiros, 2006). A aplicao consiste de um sistema gerencial para uma associao de doadores de sangue. So cadastrados doadores, funcionrios, projetos, doaes e atividades desempenhadas por esta. Seguindo o padro de camadas, foi construda sob as camadas de viso, que traz recursos da API Java Swing para telas, camada de controle, com as regras de negcio e a camada de persistncia que utiliza JPA/Hibernate. Existe um pacote de entidades que traz classes Java que mapeiam as tabelas do banco de dados e so utilizadas em todas as camadas (Pinto et al., 2009). A estria do usurio, representada na figura 5, pode ser uma nova necessidade da associao, sendo, na sua implementao, pertinente o uso de TDD. Com o ambiente e tambm com o papel do JUnit definidos, o esta estria foi construda seguindo os princpios de TDD.

3.3 UTILIZAO DE TDD

Desenvolver orientado a testes exige um conhecimento prvio do negcio e das necessidades do cliente. Esta implementao trata de regras para que um doador possa efetuar uma doao de sangue, ento a partir da estria de usurio (Figura 5) foram abstrados os requisitos e, a partir destes, definidas algumas tarefas para o desenvolvimento. Beck (2010) apresenta uma tcnica interessante para se trabalhar com TDD, criar uma lista de tarefas para uma estria de usurio. Esta lista deve contemplar cada teste a ser definido na ferramenta de teste unitrio e que iro conduzir a implementao. A figura 7 traz a lista de tarefas abstradas da estria de usurio. _____________
1 API uma interface de um conjunto de padres de programao que possibilita e facilita a construo de aplicativos de forma padronizada.

39

Figura 7. Lista tarefas para desenvolvimento Fonte: Elaborado pelo autor. Guiado por essa lista, o teste unitrio definido para cada tarefa. Inicialmente apenas o cdigo criado e executado para garantir que est sendo considerado pela aplicao e, claro, neste momento ele falha (barra vermelha). Com o teste j definido e garantido um cdigo simples implementado para que a execuo do teste passe a ser verdadeiro (barra verde). Com a aplicao sem erros e testes validados, uma refatorao foi feita no cdigo a fim de melhorar a qualidade e desempenho do mesmo. Para melhorar a compreenso, os artefatos que participaram deste ciclo sero mostrados a seguir. A Figura 8 traz um trecho do cdigo implementado no JUnit para a definio de uma situao validada.
public class ServicoRealizarDoacaoTest extends TestCase { //recuperando doadores para o teste ServicoRealizarDoacao servico = new ServicoRealizarDoacao(); Doadores doador1 = servico.recuperarDoadorPorID(1001); Doadores doador2 = servico.recuperarDoadorPorID(1002); Doadores doador3 = servico.recuperarDoadorPorID(1003); Doadores doador4 = servico.recuperarDoadorPorID(1004); //valida se idade maior ou igual a 16 e menor que 69 public void testValidarIdade(){ assertEquals(true, servico.validarIdade(doador1)); assertEquals(false, servico.validarIdade(doador2)); assertEquals(false, servico.validarIdade(doador3)); assertEquals(true, servico.validarIdade(doador4)); } //valida intervalo entre doaes, para homens 60 dias e mulheres, 90 dias public void testValidarIntervaloDoacoes(){ assertEquals(true, servico.validarIntervaloDoacoes(doador1)); //Masc, 07/01/1999 assertEquals(false, servico.validarIntervaloDoacoes(doador2)); //Masc, NULL assertEquals(true, servico.validarIntervaloDoacoes(doador3)); //Fem, 30/10/2010 assertEquals(false, servico.validarIntervaloDoacoes(doador4)); //Fem 11/07/2011 }

//nasc: //nasc: //nasc: //nasc:

19/12/1992 21/03/1996 30/06/1942 27/08/1951

Figura 8. Trecho de cdigo da classe de teste unitrio Fonte: Elaborada pelo autor.

40

A Figura 9 apresenta o cdigo j refatorado dos mtodos de validao de idade e intervalo entre doaes.
//valida as regras de idade do cenrio do usurio public boolean validarIdade(Doadores doador){ boolean isValido = true; try { Date dataNasc = format.parse(doador.getPessoas().getDataNascimento()); //invoca mtodo que realiza o calculo da idade Integer idade = calculaIdade(dataNasc); if(idade == null || idade < 16 || idade > 68){ isValido = false; } } catch (ParseException e) { e.printStackTrace(); isValido = false; } return isValido; } //valida as regras de intervalo de doaes do cenrio do usurio public boolean validarIntervaloDoacoes(Doadores doador){ boolean isValido = true; try { Date dataUltimaDoacao = format.parse(doador.getDataUltimaDoacao()); if(doador.getPessoas().getSexo().equals("M") && diferencaDiasDatas(dataUltimaDoacao) < 90){ isValido = false; }else{ if(doador.getPessoas().getSexo().equals("F") && diferencaDiasDatas(dataUltimaDoacao) < 60){ isValido = false; } } } catch (ParseException e) { e.printStackTrace(); isValido = false; } return isValido; }

Figura 9. Trecho cdigo mtodos de validao de doao Fonte: Elaborada pelo autor. Os cdigos apresentados representam apenas uma parte do cdigo necessrio para a implementao da regra de validao para a doao de sangue. Cada tarefa definida na Figura 7 passou pelo mesmo ciclo definir teste, codificar o bsico e refatorar sendo que ao validar todas as tarefas foi possvel ter um cdigo que atendesse as necessidades do usurio, isto porque cada requisito presente na estria de usurio (Figura 5) foi abstrado para um teste e este, conduziu a implementao. Outros aspectos do uso de TDD neste cenrio sero abordados no prximo tpico deste trabalho.

41

3.4 LIES APRENDIDAS

A implementao da estria de usurio de autorizao de uma doao, apesar de se tratar de um caso hipottico e ser utilizada apenas como uma aplicao de TDD propiciou vivenciar aspectos importantes sobre o uso da tcnica do TDD. J nos primeiros passos do desenvolvimento possvel perceber muitas diferenas. Antes de criar classes e definir as validaes foi preciso fazer um esboo dos testes que deveriam ser feitos, sendo cada um destes definidos como uma tarefa (Figura 7). Este ainda no era o momento de realizar a implementao no cdigo, mas sim de utilizar a sute JUnit e criar os testes. Cada teste foi sendo implementado, executado para que, ento, o cdigo referente quela validao fosse ento implementado de maneira simples, apenas para que o teste fosse executado com sucesso. Da em diante era necessrio refatorar o cdigo. Foi perceptvel a importncia da refatorao. Em determinado momento, ao fim de todos os testes, existia muito cdigo duplicado e rotinas caras, pesadas para a aplicao. Ao refatorar, este cdigo foi ficando mais limpo e claro, atingindo assim um dos objetivos do TDD. Alm desta alterao no fluxo tradicional de desenvolvimento, o fato de realizar uma alterao e executar os testes unitrios foi visto como um diferencial dessa tcnica. Desta forma possvel garantir que uma alterao no impacte em outros trechos do cdigo, sendo que se ocasionar algum erro, este logo identificado durante a execuo dos testes unitrios. Adaptar-se ao TDD parece demandar esforo da equipe, alm de mudar o fluxo das atividades. A rotina diferente, afinal a todo momento preciso definir testes e execut-los. H um aumento no tempo de desenvolvimento, mas a garantia de qualidade da aplicao desenvolvida deve compensar este aumento. Por fim entende-se que TDD uma mudana em todo o processo de desenvolvimento que busca sempre garantir qualidade e correo no que est sendo construdo, exigindose dos envolvidos um entendimento do domnio e regras do negcio e mesmo tendo um aumento no tempo de desenvolvimento tem uma validade muito grande por aumentar a garantia da qualidade.

42

CONSIDERAES FINAIS

A qualidade um aspecto que tem sido muito no desenvolvimento de software e pode ser vista como o cumprimento dos requisitos definidos para a aplicao. Garantir essa qualidade tem sido uma busca permanente entre as empresas de software maduras, que desenvolvem estudos para definir processos de construo capazes de tornar o desenvolvimento de software mais confivel e seguro. O desenvolvimento orientado a testes surgiu dessa busca, porm at sua estruturao a Engenharia de Software passou por vrias fases. Nascida dessa busca por um processo de desenvolvimento capaz de otimizar recursos e garantir que os requisitos definidos fossem alcanados, a Engenharia de Software trouxe os primeiros processos de desenvolvimento. Esses eram rgidos e sequenciais, com uma atividade iniciada apenas com o trmino de outra. Esses processos foram se adaptando s novas exigncias do mercado, principalmente agilidade, adaptabilidade, dinamismo e confiabilidade. At que no incio dos anos 2000, os chamados mtodos geis trouxeram uma nova concepo do processo, simplicidade, dinamismo e mnima documentao. Junto desses mtodos, tcnicas que aumentam qualidade, comunicao e agilidade tambm apareceram e possibilitaram que fossem combinados de modo a trazer os maiores ganhos para cada projeto. Uma tcnica presente em muitas metodologias o desenvolvimento orientado a testes ou TDD, objeto de estudo deste trabalho. Consiste de uma inverso na ordem tradicional de desenvolvimento, os testes so definidos inicialmente e conduzem todo o desenvolvimento, sendo executados repetidamente. uma tcnica aplicada a todo o projeto e no apenas aos testes. A aplicao de TDD baseada em testes unitrios, que garantem o correto funcionamento de uma unidade da aplicao e que, em conjunto, garantem qualidade de uma funo maior e, conseqentemente da aplicao como um todo. Utilizar TDD diminui a quantidade de erros encontrados e faz com que estes sejam percebidos e corrigidos mais rpido que na metodologia tradicional. Implantar TDD tambm tem aspectos negativos como dificuldade de mudana na cultura do time e o aumento do tempo de desenvolvimento. Da a

43

importncia de se definir o que se espera do projeto e suas limitaes para definir as melhores tcnicas a serem utilizadas. Tambm no destinada a projetos grandes e complexos, que trabalhem com computao distribuda, por exemplo. Finalizando, TDD vai alm dos testes e afeta todo o processo de desenvolvimento, trazendo maior cobertura de testes e entendimento do negcio para os desenvolvedores. Porm tem suas limitaes como, implantao impactante sobre o time e aumento do tempo de desenvolvimento. Devido a estas caractersticas importante analisar o projeto, a equipe para ento definir sua utilizao.

4.1 TRABALHOS FUTUROS

Estudos sobre TDD ainda tm certas restries e este trabalho buscou abordar o que e como implantar TDD. Porm existem vrios aspectos a serem abordados dentro deste tema. A seguir sero apresentadas algumas propostas para trabalhos futuros. Tratar da migrao de uma metodologia tradicional para uma gil que utilize TDD um tema muito pertinente, exigir conhecimentos de ambas as metodologias e abordar um dos pontos que mais dificultam a implantao de TDD nas empresas de desenvolvimento. O uso de objetos mocks pode facilitar a execuo de testes unitrios, uma vez que tratam as dependncias, permitindo o teste exclusivo de uma unidade. O estudo de tcnicas sobre a aplicao de mocks possibilitar um ganho de eficincia no uso de TDD. Outro tema para trabalhos futuros esta baseado nos padres de projeto orientados a testes apresentados por Beck (2010). So padres e variaes a serem utilizados juntamente com TDD. Estud-los e definir situaes onde aplic-los tambm representar um ganho na aplicao do TDD. TDD amplo e envolve a qualidade de software, estudos sobre como garantir e melhorar a qualidade dos softwares desenvolvidos tambm podem merecer para trabalhos futuros.

44

REFERNCIAS BIBLIOGRFICAS

ALMEIDA, R. R. Processo de Desenvolvimento de Software. 2007. Disponvel em: <http://www.rodrigor.com/disciplinas>. Acesso em: 08 set. 2011. AMMANN, P. Introduction to Software Testing. Cambridge UPr, City, 2008. Disponvel em: <http://www.dit.hcmut.edu.vn/~hiep/SoftwareTesting/Introduction %20to%20Software%20Testing.pdf>. Acesso em 18 set. 2011. ANDRADE, Bruno Eustquio. et al. TDD-Test Driven Development. 2011. Disponvel em: <http://pt.scribd.com/doc/53948144/Texto-Explicacao-TDD>. Acesso em 23 set. 2011. ASTELS, David. Test-Driven Development: A Practical Guide (Coad Series). 2003. Prentice Hall PTR. ASTELS, David. A new look at test-driven development. 2006. Disponvel em: <http://blog.daveastels.com/files/BDD_Intro.pdf>. Acesso em 13 set. 2011. ASTELS, David., MILLER, G., e NOVAK, M. A Practical Guide to eXtreme Programming. Prentice Hall, 2002. BASSI, Dairton. Experincias com Desenvolvimento gil. Disponvel em: <http://www.ime.usp.br/~colli/Arquivos_linkados/Dissertacao_Dairton_banca.pdf>. Acesso em: 08 set. 2010. BECK, Kent, et al. O Manifesto gil. 2001. Disponvel em: <http://hp.br.inter. net/jrotta/docs/omanifestoagil.pdf>. Acesso em: 31 ago. 2011. BECK, Kent. TDD Desenvolvimento Guiado por Testes. Bookman, 2010. Porto Alegre. BECK, K. e ANDRES, C. Extreme Programming Explained: Embrace Change. Addison-Wesley Professional, 2004. BORGES, Eduardo N. Conceitos e Benefcios do Test Driven Development. Instituto de Informtica UFRGS. 2006. Disponvel em < http://www.inf.ufrgs.br/ ~cesantin/ TDD-Eduardo.pdf>. Acesso em: 16 ago 2011. FOWLER, Martin. The new methodology. 2005. Disponvel em: <http://martinfowler .com/articles/newMethodology.html>. Acesso em: 10 ago. 2011. GOLD, R., HAMMELL, T., e SNYDER, T. Test-Driven Development: A J2EE Example. Expert's Voice. Apress, 2004. HUNT, A. e THOMAS, D. Pragmatic Unit Testing: The Pragmatic Programmers. Raleigh, 2003. Disponvel em <http://research.rmutp.ac.th/research/Pragmatic

45

%20Unit%20Testing%20in%20Csharp%20with%20NUnit.pdf>. Acesso em: 13 set. 2011. IEEE Standards Collection. Software Enginnering, IEEE Standard 610.12 1990. IEEE, 1993. Disponvel em < http://standards.ieee.org/findstds/standard/610.121990.html>. Acesso em: 25 ago. 2011. JEFFRIES, Ron. O que eXtreme Programming?. 2001. Disponvel em: <http://xprogramming.com/book/whatisxp/>. Acesso em 20 set. 2011. KOSKELA, L. Test Driven: TDD and Acceptance TDD for Java Developers. So Paulo. Manning Publications, 2007. LEWIS, E. W. Software Testing and Continuous Quality Improvement. Auerbach Publications, 2000 Disponvel em: <http://www.ittoday.info/Articles/images/ SoftwareTestingTable2.pdf>. Acesso em 14 set. 2011. MANHES, Vincius Teles. Extreme Programmin: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade, Rio de Janeiro, 2004. Novatec Editora. MARRERO, W. e SETTLE, A. Testing First: Emphasizing Testing in Early Programming Courses. 2005. Disponvel em: <http://facweb.cs.depaul. edu/asettle/research/papers/iticse2005.pdf>. Acesso em: 15 ago. 2011. MEDEIROS, Manoel Pimentel. JUnit Implementando testes unitrios em Java. Disponvel em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=1432>. Acesso em 05 out 2011. PRESSMAN, Roger S. Engenharia de Software. 6. ed. Edio. McGraw-Hill. So Paulo, 2006. PINTO, Aguinaldo Alves, et al. A Importncia da Informatizao no Gerenciamento de uma Associao de Doadores de Sangue. Unipac. 2009. Bom Despacho. RAINSBERGER, J. B. JUnit: A Starter Guid. Disponvel em: <http://articles.jbrains .ca/JUnitAStarterGuide.pdf>. Acesso em 05 out. 2011. SANTIN, Carlos Eduardo. Desenvolvimento guiado por testes e ferramentas xUnit. Instituto de Informtica UFRGS, 2006. Disponvel em: <http://www.inf.ufrgs.br/~cesantin/TDD_Artigo.pdf>. Acesso em: 15 ago. 2011. SANTOS, Rafael Luis. Emprego de Test Driven Development no desenvolvimento de aplicaes. UNB Departamento de Cincia da Computao. Brasilia, 2010. Disponvel em <http://monografias.cic.unb.br/ dspace/bitstream/123456789/258/1/monografia.pdf>. Acesso em: 20 ago. 2011.

46

SILVEIRA, Guilherme e ANICHE, Mauricio. TDD e sua influncia no acoplamento e coeso. 2011. Disponvel em <http://blog.caelum.com.br/tdd-e-sua-influencia-noacoplamento-e-coesao/>. Acesso em 19 set. 2011 SOARES, Michael dos Santos. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. UFBA, 2004. Disponvel em: <http://wiki.dcc.ufba.br/pub/Aside/ProjetoBitecIsaac/Met._Ageis.pdf>. Acesso em: 01 set. 2011. SOMMERVILLE, Ian. Engenharia de Software. 6. ed. So Paulo Addson Wesley, 2003. 592 p. VASCONCELOS, Alexandre Marcos Lins de. et al. Introduo Engenharia de Software e Qualidade de Software. UFPE, 2006. Disponvel em: <http://www.cin. ufpe.br/~if720/downloads/Mod.01.MPS_Engenharia&QualidadeSoftware_V.28.09.06. pdf>. Acesso em: 01 set. 2011. VIEGA, J. e McMANUS, J. The importance of software testing. 2000. Disponvel em <http://www.cutter.com/research/2000/crb000111.html>. Acesso em: 23 ago. 2011.