Você está na página 1de 8

Instituto Federal do Mato Grosso Ncleo Avanado de Campo Verde Tecnologia em Anlise e Desenvolvimento de Sistemas

Leonardo Guilherme Soares da Cunha Paulo Henrique Walter Junior Vidori

TEST DRIVEN DEVELOPMENT

Engenharia de Software Prof. Tiago Lacerda

Campo Verde, MT

1. Introduo Test Driven Development, ou TDD, tambm conhecido por test-first development, um conjunto de tcnicas associadas com (Extreme Programming (XP) e mtodos geis. TDD, no processo XP, a nica maneira de se codificar . Segundo Miller , TDD reivindica um desenvolvimento incremental do cdigo que inicia com testes, incluindo freqentemente testes de regresso. Uma das regras do TDD a seguinte: se voc no consegue escrever um teste para aquilo que voc est codificando, ento voc nem deveria pensar sobre codificar. Esta tcnica de desenvolvimento antiga, mas tornou-se conhecida, aps sua adoo em metodologias geis de desenvolvimento, tornando assim, um desenvolvimento incremental, onde o cdigo escrito para passar pelos testes j escritos previamente. Quando uma nova funcionalidade adicionada ao sistema, isto deve manter a estrutura simples inicial intacta, e pode ser que seja necessrio reestruturar algo. Isto, entretanto, pode quebrar alguma outra funcionalidade que j estivesse funcionado. Para garantir que isto no ir acontecer, testes automatizados devem acontecer . Atualmente, TDD tem sido usado em muitas reas de tecnologia, alm do desenvolvimento de software, como tambm no desenvolvimento de sistemas embarcados , onde alm do software, desenvolvido o hardware sob o qual ele ir ser executado. Em algumas universidades, TDD est sendo ensinado junto com as cadeiras bsicas de programao, a fim de enfatizar testes como sendo uma prtica fundamental para a carreira de informata . Este artigo pretende realizar uma reviso mostrando do que trata a TDD e o que existe de atual nesta disciplina, como tcnicas associadas, patterns e ferramentas disponveis. 2. O que Test Driven Development De acordo com Kent Beck , um mtodo gil comparvel ao ato de dirigir um carro: voc deve observar a estrada e fazer correes contnuas para se manter no caminho. Neste contexto onde a agilidade fundamental, o testador seria aquele que ajuda o motorista a chegar com segurana ao seu destino, impedindo que sejam feitas converses incorretas durante o percurso, evitando que o motorista se perca e fazendo com que ele pare e pea instrues quando necessrio. Neste ambiente, destaca-se o TDD, como sendo uma abordagem evolutiva na qual o desenvolvedor escreve o teste antes de escrever o cdigo funcional necessrio para satisfazer aquele teste .

Segundo Marrero , o objetivo principal do TDD especificao e no validao. Em outras palavras, uma forma de refletir sobre a modelagem antes de escrever cdigo funcional. J segundo Baumeister , desenvolvimento dirigido por testes uma tcnica de programao onde o principal objetivo escrever cdigo funcional limpo a partir de um teste que tenha falhado. Como efeito colateral, obtm-se um cdigo fonte bem testado. Aps escrever os casos de teste, que devem especificar apenas uma pequena parte da funcionalidade, inicialmente nem devem compilar, pois a funcionalidade ainda nem foi escrita, o desenvolvedor deve implementar o cdigo necessrio apenas para passar pelo teste. Feito isto, fica a cargo do desenvolvedor realizar o refactor do cdigo, garantindo que continue a forma mais simples de cdigo para satisfazer a determinada funcionalidade . O ciclo, de uma viso macro, poderia ser visto como: escrever poucos casos de teste, implementar o cdigo; escrever poucos casos de teste, implementar o cdigo, e assim por diante. A figura 1 ilustra como feito o processo de TDD. O processo XP sugere, que outras disciplinas sejam utilizadas junto com o TDD, como por exemplo, a pair programming (programao em par) e o refactoring. Existem vrias questes que so levantadas da adoo do TDD em um projeto. Uma delas em relao ao que no deve ser testado. Kent Beck diz que devem ser testados condies, loops, operaes e polimorfismos, porm, somente aqueles que o prprio desenvolvedor escreveu. Quanto questo sobre se os testes esto bons, h trs pontos que devem ser observados: I) se so necessrias muitas linhas de cdigo criando objetos para uma simples assero, ento h algo de errado; II) se no possvel encontrar facilmente um lugar comum para o cdigo de inicializao, ento existem muitos objetos firmemente associados. III) testes que quebram inesperadamente sugerem que uma parte da aplicao est afetando outra parte. necessrio projetar at que esta distncia seja eliminada, ou quebrando esta conexo ou trazendo as duas partes juntas. Uma vantagem significativa do TDD que ele possibilita ao desenvolvedor dar pequenos e controlados passos durante a codificao do

software . Esta prtica mais aconselhvel do que escrever grandes quantidades de cdigo de uma s vez.

3. Ciclo de Desenvolvimento
A seguinte sequncia baseada no livro Test-Driven Development by Example.

1. Adicione um teste Em Test Driven Development, cada nova funcionalidade inicia com a criao de um teste. Este teste precisa inevitavelmente falhar porque ele escrito antes da funcionalidade a ser implementada (se ele no falha, ento a funcionalidade ou melhoria 'proposta' bvia). Para escrever um teste, o desenvolvedor precisa claramente entender as especificaes e requisitos da funcionalidade. O desenvolvedor pode fazer isso atravs de casos de uso ou user stories que cubram os requisitos e excees condicionais. Esta a diferenciao entre desenvolvimento dirigido a testes entre escrever testes de unidade 'depois' do cdigo desenvolvido. Ele torna o desenvolvedor focado nos requisitos 'antes' do cdigo, que uma sutil mas importante diferena. 2. Execute todos os testes e veja se algum deles falha Esse passo valida se todos os testes esto funcionando corretamente e se o novo teste no traz nenhum equvoco, sem requerer nenhum cdigo novo. Pode-se considerar que este passo ento testa o prprio teste: ele regula a possibilidade de novo teste passar. O novo teste deve ento falhar pela razo esperada: a funcionalidade no foi desenvolvida. Isto aumenta a confiana (por outro lado no exatamente a garante) que se est testando a coisa certa, e que o teste somente ir passar nos casos intencionados. 3. Escrever cdigo O prximo passo escrever cdigo que ir ocasionar ao teste passar. O novo cdigo escrito at esse ponto poder no ser perfeito e pode, por exemplo, passar no teste de uma forma no elegante. Isso aceitvel porque posteriormente ele ser melhorado. O importante que o cdigo escrito deve ser construdo somente para passar no teste; nenhuma funcionalidade (muito menos no testada) deve ser predita ou permitida em qualquer ponto. 4. Execute os testes automatizados e veja-os executarem com sucesso

Se todos os testes passam agora, o programador pode ficar confiante de que o cdigo possui todos os requisitos testados. Este um bom ponto que inicia o passo final do ciclo TDD. 5. Refatorar cdigo Nesse ponto o cdigo pode ser limpo como necessrio. Ao re-executar os testes, o desenvolvedor pode confiar que a refatorao no um processo danoso a qualquer funcionalidade existente. Um conceito relevante nesse momento o de remoo de duplicao de cdigo, considerado um importante aspecto ao design de um software. Nesse caso, entretanto, isso aplica remover qualquer duplicao entre cdigo de teste e cdigo de produo por exemplo magic numbers or strings que ns repetimos nos testes e no cdigo de produo, de forma que faa o teste passar no passo 3. 6. Repita tudo Iniciando com outro teste, o ciclo ento repetido, empurrando a funcionalidade a frente. O tamanho dos passos deve ser pequeno - to quanto de 1 a 10 edies de texto entre cada execuo de testes. Se novo cdigo no satisfaz rapidamente um novo teste, ou outros testes falham inesperadamente, o programador deve desfazer ou reverter as alteraes ao invs do uso de excessiva depurao. A Integrao contnua ajuda a prover pontos revertveis. importante lembrar que ao usar bibliotecas externas no interessante gerar incrementos to pequenos que possam efetivamente testar a biblioteca , a menos que haja alguma razo para acreditar que a biblioteca tenha defeitos ou no seja suficientemte completada com suas funcionalidades de forma a servir s necessidades do programa em que est sendo escrito.

4.

Benefcios

O desenvolvimento baseado no TDD proporciona alguns benefcios como: * Melhor entendimento do negcio do sistema: a primeira etapa do TDD o Design, ou seja, antes de comear a implementar algum cdigo, o engenheiro deve entender o problema/funcionalidade e projetar a soluo. Essa fase extremamente importante no processo do TDD, o que geralmente acontecia antes de usarmos o TDD, era que o engenheiro comeava a implementar a funcionalidade sem entender direito o que ele realmente precisava fazer, gerando muitos bugs e retrabalho mais pra frente. Com o TDD, precisamos projetar os testes antes, e para projetarmos os testes, temos que entender o que realmente deve ser testado, fazendo

com que o engenheiro problema/funcionalidade.

entre

fundo

no

entendimento

do

* Criao de testes ricos: quando se implementa testes unitrios depois do cdigo estar pronto, voc tende a implementar testes de baixa qualidade, pois voc inconscientemente escreve um testes para rodar no cdigo produzido, e o correto seria o contrrio, seu cdigo que deveria passar no teste previamente implementado. * Maior confiana no cdigo: em pesquisa realizada em projetos que rodaram o TDD, notouse que os engenheiros entregaram um cdigo com mais confiana no trabalho produzido. * Maior valor agregado ao produto: sem dvida alguma entregar um produto ao cliente j com os testes implementados, representa uma entrega de maior valor agregado ao produto. Se voc vender bem essa idia ao cliente, e fizer com que ele entenda os benefcios dos testes, pode ser que ele at pague a mais para voc implementar os testes unitrios que j estavam previstos no seu processo de desenvolvimento, e com isso, todos ganham: o cliente, com um produto de maior qualidade e voc com o ganho da produtividade proporcionado pelo TDD. Na fase de implementao, usando TDD, quando terminamos nossa unidade de desenvolvimento, realmente acabamos. Ou seja, dificilmente temos que retornar ao cdigo futuramente para corrigir falhas, pois as mesmas j foram previamente detectadas e corrigidas durante a confeco dos testes. 5. Limitaes 1. Desenvolvimento dirigido com testes difcl de usar em situaes onde testes totalmente funcionais so requeridos para determinar o sucesso ou falha. Exemplos disso so interfaces de usurios, programas que trabalham com base de dados, e muitos outros que dependem de configuraes especficas de rede. TDD encoraja os desenvolvedores a incluir o mnimo de cdigo funcional em mdulos e maximizar a lgica, que extrada em cdigo de teste, usando Fakes mocks para representar o mundo externo.

2. Suporte gerencial essencial. Se toda a organizao no acreditar que TDD para melhorar o produto, o gerenciamento ir considerar que o tempo gasto escrevendo teste desperdcio. 3. Os prprios testes se tornam parte da manuteno do projeto. Testes mal-escritos, por exemplo, que incluem strings de erro embutidas ou aqueles que so suceptveis a falha, so caros de manter. H um risco em testes que geram falsas falhas de tenderem a serem ignorados. Assim quando uma falha real ocorre, ela pode no ser detectada. possvel escrever testes de baixa e fcil manuteno, por exemplo pelo reuso das strings de erro, podendo ser o objetivo durante a fase de refatorao descrita acima. 4. O nvel de cobertura e detalhamento de teste alcanado durante repetitivos ciclos de TDD no pode ser facilmente re-criado em uma data tardia. Com o passar do tempo os testes vo se tornando gradativamente preciosos. Se uma arquitetura pobre, um mal design ou uma estratgia de teste mal feita acarretar em mudana tardia, fazendo com que dezenas de testes falhem, por outro lado eles so individualmente consertveis. Entretanto, simplesmente deletando, desabilitando ou alterando-os vagamente poder criar buracos indetectveis na cobertura de testes. 5. Lacunas inesperadas na cobertura de teste podem existir ou occorer por uma srie de razes. Talvez um ou mais desenvolvedores em uma equipe no foram submetidos ao uso de TDD e no escrevem testes apropriadamente, talvez muitos conjuntos de testes foram invalidados, excludos ou desabilitados acidentalmente ou com o intuito de melhor-los posteriormente. Se isso acontece, a certeza de que um enorme conjunto de testes TDD sero corrigidos tardiamente e refatoraes sero mal acopladas. Alteraes pode ser feitas no resultando em falhas, entretanto na verdade bugs esto sendo introduzidos inperceptitvelmente, permanecendo indetectveis. 6. Testes de unidade criados em um ambiente de desenvolvimento dirigido por testes so tipicamente criados pelo desenvolvedor que ir ento escrever o cdigo que est sendo testado. Os testes podem consequentemente compartilhar os 'pontos cegos' no cdigo: Se por exemplo, um desenvolvedor no realizar determinadas entradas de parmetros que precisam ser checadas, muito provavelmente nem o teste nem o cdigo ir verificar essas entradas. Logo, se o desenvolvedor interpreta mal a especificao dos requisitos para o mdulo que est sendo desenvolvido, tanto os testes como o cdigo estaro errados.

7. O alto nmero de testes de unidades pode trazer um falso senso de segurana, resultando em menor nvel de de atividades de garantia de qualidade, como testes de integrao e aceitao.

6. Ferramentas Existem atualmente diversas ferramentas, tanto open-source como proprietrias, que apiam o desenvolvimento de sistemas baseados em TDD, dentre elas, podemos citar frameworks para testes unitrios, os chamados xUnits, entre os quais, o mais famoso o JUnit, e para a criao do mock objects, como tambm editores de cdigo que auxiliam no desenvolvimento tanto do cdigo como na execuo dos testes. 7. Concluso O desenvolvimento guiado por testes colabora com o aumento da qualidade dos sistemas, os desenvolvedores ficam mais corajosos e confiantes ao programar, software cresce de forma ordenada e com qualidade de design e se adapta com mais facilidade a mudanas. No incio, trabalhar com TDD pode parecer um pouco doloroso, pois temos que fazer o inverso do que estamos acostumados. Porm, com o tempo voc ir observar que essa tcnica lhe proporcionar ganhos enormes no seu processo de engenharia.

8. Bibliografia http://www.devmedia.com.br/post-10025-Test-Driven-Development-TDD.html http://pt.scribd.com/doc/34245573/Test-Driven-Development http://www.profissionaisti.com.br/2009/11/tdd-test-drivendevelopment-c-mocks-parte-iv/ http://www.heinecke.com/publications/XPandContracts.pdf http://pt.wikipedia.org/wiki/Test_Driven_Development http://www.agiledevelopmentconference.com/ 2003/files/P6Paper.pd