Test-Driven Development : uma vis ão prática

  • View
    26

  • Download
    0

Embed Size (px)

DESCRIPTION

Test-Driven Development : uma vis ão prática. Leonardo Barros, M.Sc. O que é TDD?. Test-Driven Development : Desenvolvimento Guiado por Testes Os testes s ão feitos ANTES da implementa ç ã o , diferentemente da abordagem tradicional, em que os testes s ão feitos DEPOIS da implementa çã o (*) - PowerPoint PPT Presentation

Text of Test-Driven Development : uma vis ão prática

  • Test-Driven Development: uma viso prticaLeonardo Barros, M.Sc.

  • O que TDD?Test-Driven Development: Desenvolvimento Guiado por TestesOs testes so feitos ANTES da implementao, diferentemente da abordagem tradicional, em que os testes so feitos DEPOIS da implementao (*)A autoria comumente creditada a Kent Beck, embora o conceito no seja de todo originalReferncias: Beck, K. Test-Driven Development by Example, Addison Wesley, 2003Link, J. Unit Testing in Java: How Tests Drive the Code, Morgan Kaufmann, 2003(*) No TDD, no obrigatrio que todos os testes precisem ser criados antes da implementao

  • Premissas do TDDOs testes so definidos em funo dos requisitosA implementao definida em funo dos testesCada acrscimo funcional precisa ser justificado por um teste (*)Busque sempre a implementao mais simples que atenda ao testeSe voc acha que faltou algo no cdigo, escreva mais um teste que justifique a complementao(*) Em geral, no boa prtica testar questes de layout, como posicionamento ou cores

  • O Processo do TDD (exemplo com um mtodo simples)Criar uma implementao vazia do mtodo (casca)Criar um teste para mapear um ou mais requisitos ( recomendvel comear simples)Rodar o novo teste, para confirmar que este mapeia o(s) requisito(s) (Red Bar)Implementar a soluo mais simples que faa todos os testes rodaremRodar os testes para verificar a implementao (Green Bar)Simplificar a implementao, se possvel (Refactoring)Repetir os passos 2 a 5 at atender a todos os requisitos

  • Exemplo de TDD com um mtodo simples

  • Especificao do mtodo /** * Emite um relatrio (array de Strings), indicando quantas vezes cada palavra * aparece no array fornecido. O relatrio apresentado na mesma ordem dos dados * de entrada, sendo que cada String representa uma palavra e seu nmero de * ocorrncias. Por exemplo, para a chamada: * * countWords(new String[] {"java","in","out","java","java","out"}) * * o relatrio gerado : * * ["java - 3" , "in - 1", "out - 2"] * * @param words array com as palavras a serem contadas. * @return relatrio com o cada palavra e o nmero de repeties. */ String[] countWords(String[] words) { // }

  • Revisando o mtodoRequisito(s) atendido(s)? SIMO mtodo est robusto? NOPrximos passos: construir mais testes para mapear aspectos no cobertos

  • Revisando o processoPontos negativosDesenvolvimento mais lentoMudana de hbito (inicialmente)Quem cria os testes o desenvolvedor, portanto ambos os testes e o cdigo de produo podem ter os mesmos erros conceituais A barra verde pode levar a uma falsa sensao de segurana e fazer com que a equipe relaxe nos testes de integrao e funcionais

  • Revisando o processo (cont.)Pontos positivosO desenvolvedor pode resolver o problema aos poucos, aspecto a aspecto Testes facilitam o entendimento/documentam dos requisitosBugs so percebidos mais cedo mais fcil identificar a causaA correo menos custosaO aprendizado melhorGarante uma boa base de testesA arquitetura tende a apresentar baixo nvel de acoplamentoO cdigo , naturalmente, facilmente testvel

    ConsequentementeRefactorings so menos arriscados

  • Nova versoNovo requisito: case-insensitiveBasta criar novo testeMudana no requisito: deve-se ordenar do maior para o menor, com os nmeros na frenteDeve-se primeiro ajustar os testes, para em seguida ajustar a implementaoSe encontrar uma soluo geral for complicado, comente os testes e v progressivamente restabelecendo-osRefactoring

  • Anlise Abordagem TradicionalImplementao primeiro, testar depois o que foi feitoMuitos bugs s so encontrados quando o desenvolvimento j foi encerradoEm caso de erros nas estimativas / presso entrega, testes so prejudicadosSe houver poucos testes, refactorings so arriscadosTendncia a tornar o cdigo genrico (mais complexo do que necessrio) para evitar refactorings

  • Riscos/Dificuldades do uso de TDDResistncia da equipe (mudana de cultura)Negociao do prazo com o clienteEstimativas / Acompanhamento do desenvolvimento

  • Potenciais benefcios do uso de TDDMaior facilidade de evoluo do projetoMudanas/novos requisitos so menos ameaadoresCdigo mais simplesRotatividade causa menos impactoTestes cobrem/documentam as principais funcionalidadesCdigo mais legvel

  • JUnit muito bom, masNo basta!Em uma arquitetura cliente-servidor, posso utilizar o JUnit para testar a construo dos mtodos do servidor (testes unitrios), mas e a interface grfica do cliente? Como fao testes funcionais?

  • Voc precisa de boas ferramentas!TDD um processo teoricamente possvel de ser realizado sem ferramentas - na prtica, invivelExistem diversas ferramentas que auxiliam em cada caso (embora no haja balas de prata)

  • Exemplo de ferramenta: FEST-SwingFocada em testes realizados sobre uma interface grfica Swing (Java)Um dos mdulos de uma coleo de APIs criada para simplificar o processo de testeReferncia: http://fest.easytesting.org/swing/wiki/pmwiki.php

  • Anlise da ferramentaPontos fortesOpen Source (licena Apache 2.0)Uso bastante intuitivoExtensvelTestes so escritos na mesma linguagem da implementao (Java)Comunidade bastante ativaPontos fracosDocumentao pobreJovem (incio em meados de 2007)

  • Exemplo de TDD com uma janela Swing

  • Especificao da janela (Login)Deve conter pares rtulo/campo para conta e senhaDeve conter um boto Entrar que ir validar o login e exibir uma mensagem de bem vindo ao sistemaEm caso de conta ou senha errada, deve exibir uma mensagem login invlido ao usurio

  • At aqui tudo bem, masE os problemas do Mundo Real? Interfaces GrficasArquitetura Cliente-ServidorBanco de Dadosetc

  • Exemplo de TDD mais realista

  • Modelo de trabalho proposto (Desenvolvimento)Definio de requisitosPrototipaoTestes de Aceitao iniciais (automatizar se possvel)Definio Arquitetura inicialTestes Funcionais iniciais (automatizar se possvel)DesenvolvimentoDefinio interfacesTestes unitriosImplementaoTestes de Interao

  • Modelo de trabalho proposto (Correo de bugs)Reproduo manual do problemaImplementao de teste automtico (ou manual, se o custo for muito alto)Executar teste para garantir que o problema capturadoCorrigir problemaExecutar teste para garantir que o problema foi resolvido

  • Modelo de trabalho proposto (Refactorings em cdigo sem testes)Levantamento dos requisitos da interfaceImplementao de testes automticos (ou manuais, se o custo for muito alto)Ler o cdigo atual para garantir que todos os aspectos foram tratados (se necessrio, escrever mais testes)Rodar testes para garantir que esto corretosReimplementar o mtodo aos poucos, implementando a soluo mais simples para cada teste

  • FIM... ou o incio?

    Mostrar a classe WordProcessorCopiar o primeiro teste, rodar, copiar soluo, rodar; repetir at o 4o testeCopiar o teste nullParameter - Testes caseInsensitive