INTRODUCAO Este documento contm uma introduo TestDriven desenvolvimento (TDD) e visa proporcionar uma extensa reviso da literatura,

, reunindo todos os resultados empricos relacionados com TDD que foram publicado nos artigos acadmicos e relatos de experincia em fruns cientficos. Este trabalho tambm atua como uma base para uma experincia emprica que organizado pela Agile VTT durante Outubro Novembro Dezembro 2005. Os resultados deste inqurito literatura mostram indcios de que TDD podem ajudar a melhorar a qualidade do software significativamente, em termos de taxas de falha diminuiu, quando empregado em umcontexto industrial. os resultados no mostraram diferenas marcantes na produtividade do desenvolvedor, em qualquer dos estudos includos na este trabalho. O documento est estruturado da seguinte forma: Primeiro, a tcnica TDD junto comas suas fases, introduzido. Em seguida, as concluses dos estudos existentes so classificados com base no contexto em que foram conduzida. As limitaes dos estudos tambm so discutidos aqui. Finalmente, os resultados so resumida e concluses so tiradas. TDD

TestDriven desenvolvimento (TDD) a parte central da abordagem Agile cdigo de desenvolvimento derivado de Extreme Programming (XP) (Beck 2004) e os princpios do Manifesto gil (Beck, Beedle, et al.). De acordo com a literatura, TDD no tudo o que novo; uma primeira referncia utilizao de TDD o projeto da NASA Mercury em 1960 (Larman e Basili 2003). Vrios efeitos positivos tm foi relatado para ser obtida com a TDD. Prope-se a garantir a capacidade de teste e para alcanar um cobertura de teste extremamente elevada (Astels 2003), para aumentar a confiana do desenvolvedor (Beck, 2003), para ajudar a produzir sistemas altamente coesos e fracamente acoplados e para permitir a integrao com mais freqncia que permite que as equipes maiores de programadores para trabalhar na mesma base de cdigo, pois o cdigo pode ser check-in com mais freqncia. Diz-se tambm incentivar a explicitao sobre o alcance da implementao, enquanto ajuda a separar o projeto lgico e fsico, e para simplificar o design, quando apenas o cdigo necessrio em um determinado momento implementado.(Beck 2001) Apesar do nome, TDD no uma tcnica de teste, mas sim uma tcnica de projeto e desenvolvimento em que os testes so escritos antes de o cdigo de produo (Beck, 2001). Os testes so adicionados gradualmente durante o processo de implementao e, quando o teste passado, o cdigo refatorado para melhorar a estrutura interna do cdigo. O ciclo incremental repetido at que toda a funcionalidade implementado (Astels 2003). O ciclo de TDD consiste em seis passos fundamentais: 1. Escrever um teste para uma pea de funcionalidade, 2. executar todos os testes para ver o novo teste falhar, 3. escrever cdigo que passa nos testes, 4. executar o teste para ver toda a passagem, 5. refatorar o cdigo e 6. executar todos os testes para ver o refactoring no alterar o comportamento externo.

A primeira etapa envolve simplesmente escrevendo um pedao de cdigo que testa a funcionalidade desejada. O segundo um necessrio para validar que o teste correcta, isto , o ensaio no deve passar, neste ponto, porque o comportamento em fase de execuo no deve existir ainda. No entanto, se o teste passa, o teste ou no testar o comportamento correto ou os princpios TDD no foram seguidos. O terceiro passo a escrita do cdigo. No entanto, deve ser mantido em mente para escrever apenas como cdigo pouco quanto possvel para passar no teste (Astels 2003). Em seguida, todos os testes devem ser executados, a fim de ver que a mudana no tem introduzidos quaisquer problemas em outro lugar no sistema. Uma vez que todos os testes passar, a estrutura interna do o cdigo deve ser melhorada atravs de refatorao. O ciclo acima mencionado apresentada na Figura 1 (Adaptado a partir de (Ambler 2003; Beck 2003;. Abrahamsson, Hanhineva, et al 2004)), e os seguintes subseces discutem os passos deste ciclo em mais detalhe. ESCREVENDO O TESTE Testes em TDD so chamados de testes programador. Eles so como testes de unidade com a diferena de que eles so escrito por comportamentos, e no para os mtodos. (Astels 2003) importante que o teste so escritos de modo que eles so a ordem independente, ou seja, o resultado permanece o mesmo, independentemente da seqncia em que os testes so executados (Beck, 2003). Os testes so agrupados em conjuntos diferentes de acordo com o que comportamentos que testar. Isto permite testar de uma determinada parte do sistema sem ter que executar todos os testes. Um mtodo de ensaio a unidade mais pequena e deve testar um comportamento nico, um caso de teste rene testes relacionados. um comum iluso de que um caso de teste deve conter todos os testes de uma classe especfica.Este equvoco reforado pela maioria dos plugins IDE, porque eles costumam gerar um caso de teste para cada classe contendo mtodos de ensaio para cada mtodo. A reutilizao de fixao permitido atravs da criao e pr-condies pressupostos idnticos para cada mtodo de teste com a configurao () e desmontagem () mtodos em cada caso de teste. Em deste modo, tornar-se os testes de repetvel e eles podem ser executados de forma idntica no contexto mesmo tempo de execuo hora aps hora. (Astels 2003) Ao escrever os testes, deve ser mantido em mente que os testes devem se concentrar em testar a verdadeira comportamentos, ou seja, se um sistema tem de lidar com mltiplas entradas, os testes devem refletir mltiplas entradas. igualmente importante para refazer os testes durante o ciclo de desenvolvimento, o que significa que no deve ser uma lista de 10 dados de entrada se uma lista de 3 itens levar a mesma concepo e deciso de implementao. (Beck 2003)

EXECUTAR O TESTE

Os testes automticos deve ser executado depois de cada mudana do cdigo de aplicao, a fim de assegurar que as mudanas no introduziram erros para a verso anterior do cdigo (Astels 2003). o executando dos testes geralmente realizada com o auxlio de ferramentas de teste de unidade, tal como JUnit (2005), o qual um quadro simples para escrever testes repetidos com Java. No ciclo TDD, o testedeve ser executado depois de escrever do teste, escrevendo sobre o cdigo e refactoring.

ESCREVER O CODIGO

Em TDD, a escrita de cdigo realmente um processo para tornar o trabalho de teste, isto , escrever o cdigo que passa o teste. Beck prope trs abordagens diferentes para fazer isso: fingir, triangulao, e implementao bvia. As duas primeiras so as tcnicas que so menos utilizadas no desenvolvimento concreto trabalhar. Apesar disso, eles podem ser teis para a execuo pedaos menores deum complexo maior e mais soluo, quando o desenvolvedor no tem uma viso clara sobre como implementar ouo resumo sistema. (Beck 2003) "Fake isso" podem ser empregues, por exemplo, atravs da substituio do valor de retorno de algum mtodo com um constante. Ele fornece uma maneira rpida de fazer o teste passar. Tem um efeito psicolgico, dando a programador confiana para prosseguir com refatorao e tambm cuida do controle do escopo de a partir de um exemplo concreto e, em seguida, generalizar a partir da. A implementao abstrata conduzido atravs de deteco da duplicao entre o teste e o cdigo. (Beck 2003) "Fake" implementao pode dar um empurro para a soluo certa, se o programador realmente no sabe onde comear a escrever o cdigo. Tcnica de triangulao pode ser usado para chegar abstrao correta do comportamento, ou seja, a "fingir" soluo no utilizvel mais. Por exemplo, existem pelo menos dois casos diferentes no mtodo de ensaio exigindo valores de retorno diferentes, e, obviamente, retornando da constante no satisfazer ambos eles. Depois de alcanar a implementao abstrata, a afirmao de outro torna-se redundante com o primeiro e ele deve ser eliminado. (Beck 2003) A implementao bvia usado quando o programador est confiante e sabe ao certo como implementar alguma operao. Constante prtica de "implementao bvia" pode ser exaustivo, uma vez que requer a perfeio constante. Quando os testes comeam a falhar consecutivamente, recomenda-se para praticar a "fingir" ou "triangulao" o at que a confiana retorne. (Beck 2003)

REFATORAR

Refactoring um processo de melhoria da estrutura interna atravs da edio do cdigo de trabalho existente, sem alterar seu comportamento externo (Astels 2003). essencial, porque a integridade de concepo de dispersa de software ao longo do tempo devido presso acumulada de modificaes, melhorias e correes de bugs (Fowler 2002). Em TDD usado para limpar o cdigo depois de fazer a coisa mais simples possvel fazer a passagem de teste. Refatorao do cdigo de teste to importante como refatorar o cdigo da aplicao. (Astels 2003) A ideia de refatorao realizar as alteraes como uma srie de pequenos passos, sem introduzir novos defeitos em para o sistema. Refatorao requer um conjunto forte de testes automatizados, porque geralmente realizada manualmente, eo comportamento externo do cdigo pode mudar sem querer durante esse processo, devido ao factor humano. (Fowler 2002)

CORPO EMPRICA EXISTENTE DE PROVAS Os estudos empricos sobre TDD existentes ainda so bastante limitados em nmero.Um total de treze estudos foram includos nesta pesquisa. Sete dos estudos foram conduzidos no ambiente universitrio: seis com disciplinas de graduao (Steinberg 2001; Edwards 2003; Kaufmann e Janzen 2003; Pancur e

Ciglaric, et al. 2003; Abrahamsson, Hanhineva, et al. 2004; Erdogmus, Morisio, et al.2005) e um com os alunos de ps-graduao de cincia da computao (Mller e Hagner 2002). Dos restantes cinco estudos, realizada com desenvolvedores profissionais, trs foram dispostos em ambientes industriais reais (Maximilien e Williams 2003; Lui e Chan 2004; Porra, Lundberg, et al. 2005), enquanto os trs ltimos (Langr 2001; George e Williams 2004; Geras, Smith, et al. 2004) foram baseados em participao voluntria de desenvolvedores profissionais. Para alm destes estudos acima citados, poucos trabalhos relacionados com a formao de computao e TestDriven desenvolvimento foram localizados. Uma vez que eles se concentraram em explorar TDD puramente como um abordagem pedaggica para desenvolvimento de software e forneceu resultados muito pouco ou nenhum sobre a sua efeitos para a qualidade ou os atributos de produtividade, eles foram excludos da pesquisa. O informao apresentada recolhida a partir de artigos acadmicos e relatos de experincia publicados em fruns cientficos. Os resultados dos estudos so categorizados pelo contexto. Trs dos estudos so classificados como "Realizada em um contexto industrial", uma vez que foram realizados principalmente com desenvolvedores profissionais em ambientes industriais reais em desenvolvimento um produto de software de concreto para ser entregue. Quatro estudos que ou foram realizadas com desenvolvedores profissionais execuo de exerccios destinados a esse experimento em particular ou que foram realizadas com os alunos que trabalham em close to industry configuraes visando a entrega de um produto de software de concreto so classificados como "realizado em um semiindustrial contexto ". Os restantes seis estudos so classificados como" realizada em um contexto acadmico ", porque os indivduos do teste foram em sua maioria estudantes de graduao que utilizam TDD a algum estudo especfico exerccios. Se os desenvolvedores foram profissional um tanto questionvel (Lui e Chan 2004), mas porque os desenvolvedores no foram classificados como alunos, o estudo classificado como "Realizada em um contexto industrial". Em alguns casos, o tipo de pesquisa concludo com base no seu contexto e foco, o autor deste trabalho.

PESQUISAS REALIZADAS EM UM CONTEXTO INDUSTRIAL As principais concluses dos estudos realizados em ambientes industriais esto reunidos na Tabela 1. especialmente significativo que todos os industriais estudos de caso (Maximilien eWilliams 2003; Lui e Chan 2004; Porra, Lundberg, et al. 2005) relataram taxas de defeito consideravelmente reduzidos, tanto quanto 40 - 50 % (Maximilien e Williams 2003;. Williams, Maximilien, et al 2003). Os efeitos de produtividade foram no bvio: Damm et al. (Droga, Lundberg, et al. 2005) relatrio TDD diminuindo significativamente o Prazo de entrega enquanto o Maximillien e Williams (Maximilien e Williams 2003) estudo mostra TDD para no tem diferena ou apenas um impacto pequeno para a produtividade do desenvolvedor. As experincias de desenvolvimento tambm foram relatados para ser positivo em estudos realizados em industrial configuraes: os desenvolvedores estavam dispostos a continuar o uso de TDD (Maximilien e Williams 2003) e mesmo estimado que vai reduzir o tempo de desenvolvimento mais e

mais longo o tempo, atingindo um 25 % De reduo no prximo projeto tero (Porra, Lundberg, et al. De 2005). Lui e Chan (Lui e Chan 2004) notou que os desenvolvedores que usam TDD foram capazes de corrigir os defeitos encontrados durante usurio testes de aceitao muito mais rpido.

PESQUISAS REALIZADAS NOS A SEMIINDUSTRIAL CONTEXTO

As principais concluses de estudos realizados em semiindustrial configuraes so reunidas na Tabela 2. O efeitos de qualidade de TDD no so to bvias neste contexto, com estudos realizados em industrial configuraes. No entanto, nenhum dos estudos relatam efeitos negativos de qualidade, enquanto George e Williams (George Williams e 2004) relatrio TDD para produzir cdigo que passa blackbox 18%mais testes e Langr (Langr 2001) relata sobre a qualidade do cdigo significativamente melhorada. Ao considerar a produtividade efeitos, George e Williams (George e Williams 2004) notou que TDD necessrios 16%mais tempo de desenvolvimento, enquanto no foram encontradas diferenas naprodutividade do desenvolvedor na experincia conduzida por Geras, Smith e Miller (Geras, Smith, et al. 2004). Na George Williams e experincia (George e Williams 2004), os desenvolvedores industriais encontrado TDD para melhorar a produtividade e para ser eficaz, bem como para levar a cobertura de teste elevada. Langr (Langr 2001) apresenta que TDD tambm leva a uma melhor manuteno e produz 33% mais testes quando em comparao com o test last tradicional abordagem. Abrahamsson et al. (Abrahamsson, Hanhineva, et al. 2004) relatam resultados diferentes do acima mencionado: Eles notaram os assuntos de teste em sua experimento indicado relutncia forte para o uso de TDD, e encontraram adopo deTDD difcil. O proporo de tempo, os programadores gasto no desenvolvimento de teste e cdigo de aplicao foi de 5,6% levando Rcio LOC de teste e cdigo de aplicao de 7,8%.

PESQUISAS REALIZADAS EM UM CONTEXTO ACADMICO

As principais concluses de estudos realizados nos ambientes acadmicos esto reunidos na Tabela 3. trs dos os estudos no encontraram diferenas na qualidade ao utilizar TDD (Mller e Hagner2002; Pancur, Ciglaric, et al. 2003; Erdogmus, Morisio, et al. 2005). Embora no significativas melhorias de qualidade foram percebidos, Erdogmus et al. (Erdogmus, Morisio, et al. 2005) relataram TDD de ter mais consistentes resultados de qualidade. Mller e Hagner (Mller e Hagner 2002) no encontraram diferenas claras em efeitos de qualidade nas tcnicas utilizadas tanto, mas eles perceberam que TDD permite uma melhor reutilizao. Kaufmann e Janzen (Kaufmann e Janzen 2003) constataram que TDD produz melhor qualidade em termos de fluxo de informao melhorado. Steinberg (Steinberg 2001) relataram que os alunos que praticam TDD produziu mais coesa e menos cdigo acoplado, e foram capazes de corrigir as falhas com mais facilidade. No entanto, Edwards (Edwards 2003) s foi capaz de dar nmeros concretos ao relatar que 45% menos defeitos foram encontrados ao utilizar TDD. Ao considerar os resultados a partir do ponto de vista da produtividade, os experimentos realizados com estudantes indicou que pode aumentar com TDD, em alguns casos: Na Kauffman eJanzen experimento (Kaufmann e Janzen 2003), TDD foi medido para produzir cdigo mais 50%, onde como Pan ur et al. (Pancur, Ciglaric, et al. De 2003) e Mller e Hagner (Mller eHagner 2002) fez no encontraram diferenas. Erdogmus et al. (Erdogmus, Morisio, et al. 2005)relataram um aumento produtividade, mas no h nmeros concretos estavam disponveis. Embora no tenha sido capaz de apresentar

nmeros exactos, eles criam a vantagem de produtividade para ser devido a umnmero de sinrgica efeitos, como uma melhor compreenso da tarefa e foco, uma aprendizagem mais rpida e menor esforo de retrabalho.

LIMITAES DOS ESTUDOS

APLICABILIDADE DOS RESULTADOS PARA OS AMBIENTES INDUSTRIAIS Embora existam resultados de trs experincias que estudam TDD no contexto industrial, (isto , teste indivduos foram desenvolvedores profissionais com o objetivo de entregar um produto de software para uma empresa propsito) o meio ambiente e configuraes, na maioria dos estudos, diferem significativamente do real, configuraes do projeto industrial. Isto levanta algumas preocupaes sobre sua aplicabilidade para o industrial reais contexto. Por outro lado, alguns dos estudos realizados em um semiindustrial contexto (isto , desenvolvedores profissionais implementado exerccios projetados para algum experimento em particular ou a experimento foi realizado com os alunos que trabalham em close to industry ajustes visando a entrega de um produto de software de beto), tal como (Abrahamsson, Hanhineva, et al. 2004), pode proporcionar uma analogia adequada para o contexto industrial. Os resultados de (Lui e Chan 2004) so aplicveis no Pases asiticos em desenvolvimento, e o estabelecimento industrial difere notavelmente da industrial ocidental ambiente. Cerca de metade dos estudos includos nesta pesquisa foram realizados no contexto acadmico (isto , indivduos do teste foram os alunos execuo de exerccios especificamente concebidos para o estudo) e, portanto, a validade externa poderia ser limitado. Se este for o caso, pode-se afirmar, porque os estudos comparando alunos e os profissionais concluram que as tendncias de melhoria semelhantes podem ser identificados entre os dois grupos (Runeson 2003) e que os estudantes podem fornecer um modelo adequado de os profissionais (host, Regnell, et al., 2000). Outro elemento limitando a aplicabilidade industrial destes resultados do estudo o mbito das tarefas realizado dentro dos experimentos: produtos de software reais muitas vezes consistem de vrios milhares de linhas de cdigo e exigir contribuio de vrios desenvolvedores de trabalho. No entanto, bastante muitas das experincias consistiu em vrias tarefas curtas e eram to pequenos que apenas algumas centenas de linhas de cdigo. VALIDADE INTERNA E GENERALIZAO DOS RESULTADOS

A validade interna e generalizao (validade externa, por exemplo) dos resultados do estudo so considerados por as definies de Yin Yin (2003). Eles podem ser questionvel em alguns estudos includos neste trabalho devido a vrios fatores. Uma ameaa o ambiente de investigao descontrolada, juntamente com o nvel de conformidade dos indivduos com as tcnicas estudadas. Neste contexto, a pesquisa "descontrolada ambiente " usado quando se refere ao ambiente em que os investigadores no tm controle sobre observando se a TestDriven tcnica de desenvolvimento muito utilizado, ou seja, os testes so realmente escrito antes de implementar o cdigo. Este o caso na maior parte dos estudos includos no presente trabalho, embora nenhum deles realmente explica como ou se esta ameaa foi superada. Outra questo que limita a validade e abrangncia dos resultados so as variveis incontrolveis no os estudos. Se as variveis no pode ser isolado, difcil a concluir que os resultados so dependentes quais variveis. Por exemplo, na experincia de George e Williams (George e Williams, 2004), os resultados so aplicveis a uma combinao de TDD e programao do par.Tambm impossvel

comparar o resultados de diferentes estudos diretamente porque tinham diferentes pontos de comparao e, como mencionado anteriormente, alguns estudos avaliaram diferentes processos de desenvolvimento de software, juntamente com TDD. As mtricas utilizadas foram tambm deixou indefinido em alguns estudos. CONCLUSAO Os estudos empricos existentes fornecer informaes valiosas sobre TestDriven desenvolvimento. No entanto, a comparao dos estudos difcil, uma vez que o seu foco e as mtricas usadas para descrevem certos efeitos variaram de um estudo para outro. As limitaes dos estudos discutido em o captulo anterior pode deprimir o significado de seus resultados, principalmente em relao ao industrial aplicabilidade. Em alguns estudos, os resultados tambm so relatados com evidncia anedtica. Uma das descobertas mais importantes que a qualidade do software parece melhorar com o TDD. O trs estudos realizados no ambiente industrial, todos relataram melhora na qualidade. O efeito semelhante no era to evidente nos estudos realizados no semiindustrial ou contexto acadmico, mas por outro lado, nenhum desses estudos relataram diminuio da qualidade, enquanto cinco dos dez estudos relataram indicaes para a melhoria. Os resultados relacionados com a produtividade do desenvolvedor eram contraditrias. No industrial e semiindustrial contexto, a produtividade foi avaliada principalmente contra o tempo gasto na implementao da tarefas: Os resultados variam de 16% aumentou o tempo de desenvolvimento de projeto "diminuiu significativamente leadtime ". Os estudos realizados no mbito acadmico foram principalmente com a quantidade de implementado o cdigo quando se avalia a produtividade do desenvolvedor: Em dois dos seis estudos, a produtividade no era aplicvel. A partir dos restantes quatro estudos, dois relataram TDD a ser mais produtivo e dois no encontraram diferenas para o seu ponto de comparao. As principais limitaes relativas aplicabilidade desses resultados para ambientes industriais so notveis diferenas com as configuraes do projeto e escopo ao se comparar a um contexto concreto industrial. O maior ameaa para a validade interna e generalizao destes resultados, por exemplo, a presena de qualidade dspares e variveis de produtividade. Tambm foi notado que no foram encontradas pesquisas concentrando-se nos efeitos de design de qualidade, em que TDD proposta para ter impacto. Com base nos resultados dos estudos existentes, pode concluir-se que TDD parece melhorar software de qualidade, especialmente quando utilizado num contexto industrial. Os resultados no eram to evidentes no semiindustrial ou contexto acadmico, mas nenhum desses estudos relataram diminuio da qualidade quer. Os efeitos de produtividade do TDD no eram muito bvio, e os resultados variam independentemente do contexto do estudo. No entanto, h indcios de que TDD no necessariamente diminuir a a produtividade do desenvolvedor ou prorrogar os prazos de entrega do projeto: Em alguns casos a produtividade, significativa melhorias foram alcanadas com TDD, enquanto apenas dois dos treze estudos relataram diminuio produtividade. No entanto, em ambos os estudos da qualidade foi melhorada. A evidncia emprica sobre o uso prtico de TDD e seus impactos no desenvolvimento de software ainda esto bastante limitado. Existe definitivamente uma necessidade de mais pesquisas, especialmente no contexto industrial, em Para ser capaz de generalizar os resultados apresentados neste trabalho em um contexto maior. Outra questo observou durante este trabalho foi o fato de que nenhum relatrio material emprico sobre os efeitos de qualidade de design TDD proposto para ter impacto sobre a, ou seja, acoplamento e de coeso poderia ser encontrado.