Desenvolvimentoorientado a testes<br />Denis Ferrari<br />
SobreDenis Ferrari<br />GraduandoemSistemas de informaçãopelaFAESA;<br />Arquiteto de software;<br />Ministrapalestras e t...
Objetivosdapalestra<br />Apresentar a metodologiaágile seusvalores.<br />Apresentar o desenvolvimentoorientado a testescom...
MetodologiaÁgil<br />
MetodologiaÁgil<br />Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto ...
Histórico<br />Começou em um encontro em Fevereiro de 2001, Utah, USA.  com os seguintes representantes:  Extreme Programm...
Conceitos<br />DEFINIÇÃO:Movimento iniciado por programadores experientes e consultoresem desenvolvimento de software. <br...
Assinaram o manifesto:<br />Kent Beck, <br />Mike Beedle, <br />Arie van Bennekum, <br />AlistairCockburn,WardCunningham, ...
TDD<br />
TDD é uma técnica de desenvolvimento de software cujo processo é formado por pequenas iterações para o desenvolvimento de ...
Objetivo do TDD: <br />código limpo que funciona<br />“Mantra” do TDD: vermelho-verde-refatorar<br />Codifique o teste;<br...
Garante a existência de testes unitários completos e atualizados, que:<br />Eliminam o medo de alterarmos alguma coisa que...
Testes de Unidade;<br />Testes de Integração;<br />Testes de Sistema;<br />Testes de Integração de Sistema;<br />Testes de...
A Metodologia TDD é conduzida através dos “testes do programador”.<br />Frequentemente esses testes são chamados de “teste...
A “Espiral da Morte” do Teste<br />O ciclo mortal do “estou sem tempo para testar”:<br />
1. Construa testes isolados uns dos outros<br />Um caso de teste não deve depender do sucesso de outro para funcionar;<br ...
Mas o que testamos?<br />Fluxos Condicionais (IFs, Switches, etc.)<br />Polimorfismos<br />Loops<br />Operações<br />Etc.....
Exemplo de “Lista de Testes” para o caso de uso “Realizar Transferência Bancária”:<br />Realizar uma transferência normal ...
Exemplo de “Lista de Testes” para o caso de uso “Matricular Aluno em Disciplina”:<br />Matricular com sucesso;<br />Tentar...
3. Primeiro o  Teste<br />Oportunidade para pensar no design (projeto) das classes<br />Controlar o escopo do que será imp...
Exemplo: Testar o envio da string “Teste” através de um socket.<br />Princípios<br />publicvoidTestarComunicacaoSocket()<b...
5. Dados para Teste<br />Não escolha números mágicos se eles não tiverem um significado específico no teste. Por exemplo, ...
6. Dados com Significado Evidente<br />Lembre que está escrevendo um teste para alguém ler, e não somente para ser executa...
Trata sobre quando escrever, onde escrever e quando parar de escrever testes.<br />Qual o próximo teste da lista a impleme...
Testes de Estudo<br />Devemos escrever testes para componentes ou bibliotecas de terceiros que, supostamente, funcionam?<b...
Testes de Outras Funcionalidades<br />Sempre que uma discussão desviar do assunto principal e entrar em outras questões, e...
Defeitos Reportados<br />Sempre que um defeito é reportado nossa primeira ação deve ser escrever um caso de teste que repr...
Técnicas mais detalhadas sobre como escrever testes.<br />Subdividir Testes<br />Quando um teste ficou grande demais e voc...
Uma vez que você tenha um teste vermelho, busque torná-lo verde o quanto antes.<br />Use os padrões que serão discutidos p...
“Fake it ‘til youmake it” (simule até construir realmente)<br />Por exemplo, qual é a forma mais simples de implementar o ...
Triangulação<br />Quando você tem dois ou mais testes, você precisa de uma implementação que atenda a todos simultaneament...
Implementação Óbvia<br />Se você consegue implementar algo diretamente, então implemente. Para que utilizar “fake” ou tria...
Informaçõesparacontato<br />E-mail/MSN: denisferrari@live.com<br />Gtalk: denis.sisinf@gmail.com<br />Site: www.denisferra...
Upcoming SlideShare
Loading in …5
×

TDD (Resumo)

5,265 views

Published on

Arquivo que uso para apresentar o TDD e Agile.

Published in: Technology, Business
  • Be the first to comment

TDD (Resumo)

  1. 1. Desenvolvimentoorientado a testes<br />Denis Ferrari<br />
  2. 2. SobreDenis Ferrari<br />GraduandoemSistemas de informaçãopelaFAESA;<br />Arquiteto de software;<br />Ministrapalestras e treinamentos;<br />Consultor de negócios;<br />MCP, MCTS (Web Applications e Distributed Applications), MCPD (Web Applications);<br />EscreveartigosparaosportaisImasters, Linha de código e osdisponibilizatambémemseu blog.<br />9 anos de experiência no mercado de TI capixabaatuandocomoInstrutor, Web Master, DesenvolvedorSênior e Gerente de Projetos;<br />
  3. 3. Objetivosdapalestra<br />Apresentar a metodologiaágile seusvalores.<br />Apresentar o desenvolvimentoorientado a testescomoumaalternativaaodesenvolvimentotradicional.<br />
  4. 4. MetodologiaÁgil<br />
  5. 5. MetodologiaÁgil<br />Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.<br />http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software<br />
  6. 6. Histórico<br />Começou em um encontro em Fevereiro de 2001, Utah, USA. com os seguintes representantes: Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-DrivenDevelopment, Pragmatic Programming, e outros;<br />O objetivo do encontro foi discutir alternativas ao rigoroso processo de documentação necessário para o processo de desenvolvimento de software;<br />Deu origem ao &quot;Manifesto Ágil&quot; assinado pelos dezessete participantes do encontro.<br />
  7. 7. Conceitos<br />DEFINIÇÃO:Movimento iniciado por programadores experientes e consultoresem desenvolvimento de software. <br />PRINCÍPIOS:Indivíduos e interações X processos e ferramentas;Software funcional X documentação abrangente;Colaboração com o cliente X negociação de contratos;Adaptação a mudanças X seguir plano inicial.<br />http://agilemanifesto.org/<br />
  8. 8. Assinaram o manifesto:<br />Kent Beck, <br />Mike Beedle, <br />Arie van Bennekum, <br />AlistairCockburn,WardCunningham, <br />Martin Fowler, <br />James Grenning, <br />Jim Highsmith,<br />Andrew Hunt, <br />Roland Jeffries, <br />Jon Kern, <br />Brian Marick, <br />Robert C. Martin, <br />Steve Mellor, <br />Ken Schwaber, <br />Jeff Sutherland; <br />Dave Thomas.<br />
  9. 9. TDD<br />
  10. 10. TDD é uma técnica de desenvolvimento de software cujo processo é formado por pequenas iterações para o desenvolvimento de uma nova funcionalidade, começando pela implementação de um caso de teste, depois pelo código necessário para fazer o teste passar, e finalmente pela refatoração do código visando melhor acomodar as mudanças feitas.<br />Não é um método para testar software, mas para construir software.<br />TDD vem do conceito de “test-first programming” do XP (Extreme Programming), mas acabou ganhando tanto interesse, que hoje tem sido adotado independente do XP e das técnicas de programação ágil;<br />Introdução ao TDD (1/2)<br />
  11. 11. Objetivo do TDD: <br />código limpo que funciona<br />“Mantra” do TDD: vermelho-verde-refatorar<br />Codifique o teste;<br />Faça ele compilar e executar (não deve passar - vermelho);<br />Implemente o requisito e faça o teste passar (verde);<br />Refatore o código;<br />Introdução ao TDD (2/2)<br />
  12. 12. Garante a existência de testes unitários completos e atualizados, que:<br />Eliminam o medo de alterarmos alguma coisa que funciona (testada manualmente), e acabarmos introduzindo algum problema;<br />Nos permite utilizar refatoração (substituir uma implementação por outra equivalente) de forma muito mais agressiva devido à facilidade dos testes verificarem o resultado.<br />Diminui a quantidade de erros por linha de código (código-fonte de mais qualidade)<br />Testes unitários servem como especificação de como os componentes do sistema funcionam;<br />Nos leva a produzir componentes de software mais desacoplados, para garantir o isolamento dos testes, o que acaba favorecendo o projeto do sistema.<br />Principais Benefícios do TDD<br />
  13. 13. Testes de Unidade;<br />Testes de Integração;<br />Testes de Sistema;<br />Testes de Integração de Sistema;<br />Testes de Aceitação;<br />Tipos de Testes<br />
  14. 14. A Metodologia TDD é conduzida através dos “testes do programador”.<br />Frequentemente esses testes são chamados de “teste de unidade”, mas esse nem sempre é o caso (pode ser teste de integração).<br />É importante destacar que não se trata dos testes de sistema (caixa preta) nem os de aceitação (feitos pelo usuário final)<br />Tipos de Testes<br />
  15. 15. A “Espiral da Morte” do Teste<br />O ciclo mortal do “estou sem tempo para testar”:<br />
  16. 16. 1. Construa testes isolados uns dos outros<br />Um caso de teste não deve depender do sucesso de outro para funcionar;<br />Deve ser possível executar um caso de testes isoladamente, sem executar nenhum outro;<br />2. Comece definindo uma “TestList”<br />De modo geral para uma mesma classe ou método a ser testado, existirão diferentes casos de teste. Liste-os primeiro (brain-storm);<br />Provavelmente ao longo do desenvolvimento você adicionará novos casos de teste à lista;<br />Princípios<br />
  17. 17. Mas o que testamos?<br />Fluxos Condicionais (IFs, Switches, etc.)<br />Polimorfismos<br />Loops<br />Operações<br />Etc..<br />Princípios<br />
  18. 18. Exemplo de “Lista de Testes” para o caso de uso “Realizar Transferência Bancária”:<br />Realizar uma transferência normal (bem sucedida);<br />Tentar transferir uma quantidade superior ao saldo da conta de origem;<br />Verificar atomicidade no caso de falha de sistema antes de concluir a operação;<br />Conta de origem inativa;<br />Conta de destino inativa;<br />Valor transferido menor que zero;<br />Princípios<br />
  19. 19. Exemplo de “Lista de Testes” para o caso de uso “Matricular Aluno em Disciplina”:<br />Matricular com sucesso;<br />Tentar matricular sem atender disciplinas pré-requisito;<br />Tentar matricular sem atender pré-requisito de crédito;<br />Tentar matricular com conflito de horário;<br />Tentar matricular sem vaga;<br />Tentar matricular em disciplina já cumprida;<br />Tentar matricular em disciplina que já está matriculada (outra turma);<br />Tentar matricular em disciplina que já está matriculada (mesma turma);<br />Princípios<br />
  20. 20. 3. Primeiro o Teste<br />Oportunidade para pensar no design (projeto) das classes<br />Controlar o escopo do que será implementado – somente o necessário para atender o teste corrente.<br />4. Primeiro a Assertiva<br />É melhor pensarmos no que significa o sucesso do caso de teste antes de pensarmos no restante:<br />Vou precisar de criar um novo método?<br />Em qual classe?<br />Qual será o nome dele e seus parâmetros?<br />“Primeiro a assertiva” está para o caso de teste assim como “Primeiro o teste” está para o caso de uso;<br />Princípios<br />
  21. 21. Exemplo: Testar o envio da string “Teste” através de um socket.<br />Princípios<br />publicvoidTestarComunicacaoSocket()<br /> {<br />Assert.IsTrue(readerSocket.Close());<br />Assert.AreEqual(“Qualidata”, buf);<br /> }<br />publicvoidTestarComunicacaoSocket()<br /> {<br /> string buf = reader.Contents();<br />Assert.IsTrue(readerSocket.Close());<br />Assert.AreEqual(“Qualidata”, buf);<br /> }<br />publicvoidTestarComunicacaoSocket()<br /> {<br />SocketreaderSocket = newSocket(“localhost”, 8080);<br /> string buf = reader.Contents();<br />Assert.IsTrue(readerSocket.Close());<br />Assert.AreEqual(“Qualidata”, buf);<br /> }<br />publicvoidTestarComunicacaoSocket()<br /> {<br />Serverserver = newServer(8080, “Teste”);<br />SocketreaderSocket = newSocket(“localhost”, 8080);<br /> string buf = reader.Contents();<br />Assert.IsTrue(readerSocket.Close());<br />Assert.AreEqual(“Qualidata”, buf);<br /> }<br />
  22. 22. 5. Dados para Teste<br />Não escolha números mágicos se eles não tiverem um significado específico no teste. Por exemplo, se não faz diferença utilizar “1”, “2” ou “1365”, preferia “1”. <br />Evite passar o mesmo valor para diferentes parâmetros. Por exemplo, para testar um método Operacao(int x, int y), não utilize Operacao(2,2), pois “Operacao” pode inverter “x” e “y” e o teste ainda assim passar. Prefira, por exemplo, Operacao(2,3).<br />Dê preferência a dados do mundo real, especialmente quando você tem algum sistema legado com dados que podem ser aproveitados<br />Princípios<br />
  23. 23. 6. Dados com Significado Evidente<br />Lembre que está escrevendo um teste para alguém ler, e não somente para ser executado pelo computador.<br />Tente escrever na assertiva expressões que não só representem o valor final esperado, mas o que eles significam.<br />Exemplo:<br />Princípios<br /> [Test]<br />publicvoid Testar_Fatorial_8()<br /> {<br />Assert.AreEqual(40320, Matematica.Fatorial(8));<br /> }<br /> [Test]<br />publicvoid Testar_Fatorial_8()<br /> {<br />Assert.AreEqual(8 * 7 * 6 * 5 * 4 * 3 * 2, Matematica.Fatorial(8));<br /> }<br />
  24. 24. Trata sobre quando escrever, onde escrever e quando parar de escrever testes.<br />Qual o próximo teste da lista a implementar?<br />Escolha um teste que você esteja confiante que pode implementá-lo facilmente;<br />Não comece pelo teste mais realístico (completo), pois você será forçado a implementar um monte de coisas para atender o teste.<br />Siga na direção “mais conhecidos” para “pouco conhecidos”<br />Cada iteração “red/green/refactor” deve levar apenas alguns minutos.<br />Exercício: Se você estiver construindo uma lista encadeada, qual seria seu primeiro caso de teste?<br />“Red Bar Patterns”<br />
  25. 25. Testes de Estudo<br />Devemos escrever testes para componentes ou bibliotecas de terceiros que, supostamente, funcionam?<br />Sim. Para estudar e documentar seu uso.<br />Esse é uma forma de assegurar-se sobre como utilizar tal biblioteca de forma a obter os resultados esperados e documentar seu uso (considerando especificamente suas necessidades, e não todos os recursos da biblioteca).<br />“Red Bar Patterns”<br />
  26. 26. Testes de Outras Funcionalidades<br />Sempre que uma discussão desviar do assunto principal e entrar em outras questões, essa pode ser uma hora de adicionar novos casos de teste à sua lista (para a funcionalidade em questão) e voltar para o assunto principal.<br />“Red Bar Patterns”<br />
  27. 27. Defeitos Reportados<br />Sempre que um defeito é reportado nossa primeira ação deve ser escrever um caso de teste que reproduza o problema. Se isso for feito certamente o problema será resolvido.<br />Testes de Regressão<br />Consiste em testar novamente uma funcionalidade que foi implementada e testada anteriormente;<br />Teoricamente, após qualquer alteração no sistema, todo o sistema deveria ser testado para garantir que essa alteração não tenha introduzido algum efeito colateral indesejável.<br />Uma boa prática é executar testes de regressão de todo o sistema, todos os dias, à noite, e reportar os problemas encontrados para a equipe. Existem softwares para gerenciar isso.<br />“Red Bar Patterns”<br />
  28. 28. Técnicas mais detalhadas sobre como escrever testes.<br />Subdividir Testes<br />Quando um teste ficou grande demais e você está demorando muito para conseguir implementá-lo (mais de 10 min já deve te encomodar), pode ser melhor dividir o teste em testes menores até conseguir fazer o teste maior passar.<br />MockObjects<br />Como testar objetos que dependem de recursos externos custosos ou complexos, como bancos de dados e webservices, por exemplo?<br />Crie uma versão falsa ou simulada do objeto (“fake”) que retorne valores constantes.<br />Referência: www.mockobjects.com<br />Ferramentas para .NET: NMock e RhinoMocks.<br />“TestingPatterns”<br />
  29. 29. Uma vez que você tenha um teste vermelho, busque torná-lo verde o quanto antes.<br />Use os padrões que serão discutidos para conseguir isso rapidamente, mesmo que o resultado seja algo que você não aceita conviver nem por uma hora.<br />“Green Bar Patterns”<br />
  30. 30. “Fake it ‘til youmake it” (simule até construir realmente)<br />Por exemplo, qual é a forma mais simples de implementar o código abaixo?<br />A forma mas direta seria:<br />“Green Bar Patterns”<br />publicvoidTestarSoma() {<br />Assert.AreEqual(5, Somar(2,3));<br /> }<br />publicvoidTestarSoma() {<br />Assert.AreEqual(5, Somar(2,3));<br /> }<br />publicint Somar(int x, int y) {<br />return 5;<br /> }<br />
  31. 31. Triangulação<br />Quando você tem dois ou mais testes, você precisa de uma implementação que atenda a todos simultaneamente.<br />Agora a solução trivial (constante) não atende mais, e somos forçados e implementar algo mais abrangente.<br />É claro que esse exemplo é apenas ilustrativo. Se você já tem uma implementação correta óbvia, então implemente. Senão, “fake it”.<br />“Green Bar Patterns”<br />Página 31<br />publicvoidTestarSoma() <br /> {<br />Assert.AreEqual(5, Somar(2,3));<br />Assert.AreEqual(7, Somar(3,4));<br /> }<br />
  32. 32. Implementação Óbvia<br />Se você consegue implementar algo diretamente, então implemente. Para que utilizar “fake” ou triangulação?<br />Mas quando você achar que sabe implementar e se deparar com uma barra vermelha? Depois você descobre, errei aqui, e aí outra barra vermelha! Talvez seja hora de dividir o problema em problemas menores.<br />Acreditar que você sempre vai conseguir acertar e escrever o código mais simples para o problema diretamente é exigir de você perfeição.<br />“TestingPatterns”<br />
  33. 33.
  34. 34. Informaçõesparacontato<br />E-mail/MSN: denisferrari@live.com<br />Gtalk: denis.sisinf@gmail.com<br />Site: www.denisferrari.com<br />Blog: desenvolvimento.denisferrari.com<br />Twitter: @denisferrari<br />

×