Teste Driven Development

1.090 visualizações

Publicada em

Só um cadiquinho de TDD

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.090
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
29
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Teste Driven Development

  1. 1. [ TDD] Test Driven Development Autor: Eduardo R. Carvalho email: ercarval@gmail.com @ercarval Autor: Eduardo R. Carvalho Facebook : ercarval email: ercarval@gmail.com $ 1.0
  2. 2. [ TDD ] • O que é • Metodologia • Testes e Ciclo de Desenvolvimento de SW • JUnit • JUnit & NetBeans • Best Practices • Resumo6/4/2012 Eduardo R Carvalho 2
  3. 3. [TDD] – Test-Driven Development • Metodologia que utiliza de Testes para prover informações para tomada decisões de forma rápida e eficaz. • Promove o desenvolvimento de software de uma maneira simples e incremental. Não somente maximiza a qualidade e o design do software, como também simplifica o processo de desenvolvimento. • TDD é uma das práticas do Extreme Programming (XP). As práticas do XP foram formuladas por Kent Beck e Ron Jeffries a partir de suas experiências no desenvolvimento de uma sistema de pagamento para a Chrysler. As idéias gerais por trás do XP são simplificar o processo de desenvolvimento simples e manter um processo contínuo de desenvolvimento em um ciclo curto que fornece um feedback constante do estado do software. As idéias do TDD tem ganho uma grande aceitação nos meio dos desenvolvimento e projetos de software.6/4/2012 Introução a Java 3
  4. 4. [TDD] - Metodologia  Baseada em dois Conceitos Básicos.  Testes Unitários  “Refactoring”  Composto nos seguintes passos: 1. Escrever um teste que define como você acha que pequeno pedaço da aplicação deveria se comportar. 2. Fazer o teste rodar da maneira mais fácil e rápida que você pode. Não se preocupe com a qualidade do código, apenas faça funcionar. 3. Enxugue o código. Agora que o código esta funcionando corretamente, dê um passo para trás e refatore para remover qualquer duplicação ou qualquer outro problema que foi apresentado para tornar o teste executável.6/4/2012 Introução a Java 4
  5. 5. [TDD] - Metodologia  TDD é um processo iterativo e você repete estes passos inúmeras vezes até que você fique satisfeito com o novo código.  A maneira que TDD trabalha é através de requisitos, ou casos de uso que são decompostos em um conjunto de comportamentos que são premissas para atender o requisito. Para cada comportamento do sistema, a primeira coisa a se fazer é escrever um teste unitário que irá testar este comportamento. O teste unitário primeiro, portanto temos um conjunto bem definido de critérios que podemos utilizar para mensurar a quantidade de código necessário que foi escrito para implementar este comportamento. Um dos benefícios de se escrever o teste primeiro é que ele ajuda a definir o comportamento do sistema de uma maneira mais clara e responder algumas perguntas do modelo.6/4/2012 Introução a Java 5
  6. 6. [TDD] - Como Adotar ?  Convencendo as pessoas a utilizar TDD Desenvolver software é um risco assumido. É quase impossível entregar um projeto dentro do orçamento e do prazo. De acordo com um estudo da Gartner Group, 30% dos projetos falham e não chegam aos seus objetivos, e 70% são entregues em atraso ou fora do orçamento previsto. Claramente existe a necessidade de melhorar este processo, mas a questão é como. TDD pode ser parte da resposta, mas antes de convencer as pessoas a utilizar TDD é preciso entender e apresentar os problemas do processo atual. Uma vez entendido as falhas do processo corrente, é preciso entender como utilizar TDD para suprir estas falhas e utilizar este conhecimento para convencer as outras pessoas que isso irá funcionar.6/4/2012 Introução a Java 6
  7. 7. [TDD] - Como Adotar ?  Encontrando as falhas no processo corrente. O processo mais usual quando não se pratica TDD é o famoso modelo cascata ( análise dos requisitos, modelo, código e o teste). A maioria dos problemas relacionados ao desenvolvimento de software é má comunicação da equipe e uma execução falha. Para entender as falhas do processo corrente, devemos responder algumas perguntas básicas como: – Qual é a maior causa dos bugs no softwares ? – Qual é a maor causa dos atrasos no cronograma ? – Qual é a média de bugs a cada 1000 linhas de código escrito ? – Como o processo reage a uma mudança de requisito. – Qual a fase do projeto que mais tenho problemas ? (Desing, código, integração, etc..)6/4/2012 Introução a Java 7
  8. 8. [TDD] - Testes no ciclo de vida do SW  Testes formais podem e devem ser definidos em todas as etapas do desenvolvimento de um software. Mesmo no caso de não poderem ser automatizados, defini-los precisamente permite identificar desde cedo problemas mais sérios com os requisitos ou a modelagem de uma aplicação. Podemos dizer que, quando faltam informações para a definição formal de um teste em termos de entradas exatas e de resultados esperados, isso significa que os requisitos ainda não foram suficientemente entendidos e documentados.  Passado o levantamento de requisitos e a modelagem de negócios de uma aplicação, os testes passam a se focar mais em aspectos particulares da implementação, o que aumenta a demanda pela sua automação. Neste momento, a falta de informações suficientes para se implementar um teste automatizado pode indicar que as especificações de classes, pacotes, componentes, formatos de dados etc. ainda estão incompletas, ou então que surgiram requisitos novos ainda não completamente documentados.  O desenvolvimento orientado a testes traz o benefício de validar de modo objetivo os requisitos documentados desde o início do ciclo de vida. O TDD expõe erros, omissões e inconsistências que de outra forma só seriam detectados quando já houvesse código executável entregue ao usuário.6/4/2012 Introução a Java 8
  9. 9. [TDD] - Testes no ciclo de vida do SW  Um exemplo de processo de desenvolvimento e os tipos de testes que são produzidos em cada etapa. Vale a pena ressaltar aqui que em muitos casos as mesmas tecnologias e ferramentas podem ser utilizadas para construir diferentes tipos de testes. A distinção entre, por exemplo, “testes de unidade” e “testes de sistema” é feita em relação à finalidade de cada teste, e não em relação à sua forma.6/4/2012 Introução a Java 9
  10. 10. [TDD] Alguns Frameworks de apoio  JUnit  http://www.junit.org  EasyMock  http://easymock.org  JMock  http://www.jmock.org/  Mockito  http://code.google.com/p/mockito/  Spring  http://www.springsource.org/  iMacros  http://www.iopus.com/download/6/4/2012 Introução a Java 10
  11. 11. [TDD] – JUnit : O que é ?  Um framework que facilita o desenvolvimento e execução de testes de unidade em código Java  Uma API para construir os testes  Aplicações para executar testes  A API  Classes Test, TestCase, TestSuite, etc. oferecem a infraestrutura necessária para criar os testes  Métodos assertTrue(), assertEquals(), fail(), etc. são usados para testar os resultados.  Suportado por varias IDES (Eclipse, NetBeans, JDeveloper, etc...).6/4/2012 Introução a Java 11
  12. 12. [TDD] – JUnit : Para que Serve ?  Testar é uma boa prática, mas é chato; JUnit torna as coisas mais agradáveis, facilitando:  A criação e execução automática de testes  A apresentação dos resultados  JUnit pode verificar se cada unidade de código funciona da forma esperada  Permite agrupar e rodar vários testes ao mesmo tempo  Na falha, mostra a causa em cada teste  Serve de base para extensões6/4/2012 Introução a Java 12
  13. 13. [TDD] – JUnit : Arquitetura  Diagrama de Classes6/4/2012 Introução a Java 13
  14. 14. [TDD] – JUnit : Como Usar ?  Há várias formas de usar o JUnit. Depende da metodologia de testes que está sendo usada  Código existente: precisa-se escrever testes para classes que já foram implementadas  Desenvolvimento guiado por testes (TDD): código novo só é escrito se houver um teste sem funcionar6/4/2012 Introução a Java 14
  15. 15. [TDD] – JUnit : Testar Código Existente  Exemplo de um roteiro típico 1. Crie uma classe que estenda junit.framework.TestCase para cada classe a ser testada import junit.framework.*; class SuaClasseTest extends TestCase {...} 2. Para cada método xxx(args) a ser testado defina um método public void testXxx() no test case  SuaClasse:  public boolean equals(Object o) { ... }  SuaClasseTest:  public void testEquals() {...}  Sobre escreva o método setUp(), se necessário  Sobre escreva o método tearDown(), se necessário6/4/2012 Introução a Java 15
  16. 16. [TDD] – JUnit : Guiar Desenvolvimento  Cenário de Test-Driven Development (TDD) 1. Defina uma lista de tarefas a implementar 2. Escreva uma classe (test case) e implemente um método de teste para uma tarefa da lista. 3. Rode o JUnit e certifique-se que o teste falha 4. Implemente o código mais simples que rode o teste  Crie classes, métodos, etc. para que código compile  Código pode ser código feio, óbvio, mas deve rodar! 5. Refatore o código para remover a duplicação de dados 6. Escreva mais um teste ou refine o teste existente 7. Repita os passos 2 a 6 até implementar toda a lista6/4/2012 Introução a Java 16
  17. 17. [TDD] – JUnit : Como Implementar  Dentro de cada teste, utilize os métodos herdados da classe TestCase  assertEquals(objetoEsperado, objetoRecebido),  assertTrue(valorBooleano), assertNotNull(objeto)  assertSame(objetoUm, objetoDois), fail (), ...  Exemplo de test case com um setUp() e um teste: 1. public class CoisaTest extends TestCase { 2. // construtor padrão omitido 3. private Coisa coisa; 4. public void setUp(){ coisa = new Coisa("Bit"); } 5. public void testToString() { 6. assertEquals("<coisa>Bit</coisa>", 7. coisa.toString() ); 8. } 9. }6/4/2012 Eduardo R Carvalho 17
  18. 18. [TDD] – JUnit : Como Funciona ?  O TestRunner recebe uma subclasse de junit.framework.TestCase  Usa reflection para achar métodos  Para cada método testXXX(), executa:  o método setUp()  o próprio método testXXX()  o método tearDown()  O test case é instanciado para executar um método testXXX() de cada vez.  As alterações que ele fizer ao estado do objeto não afetarão os demais testes  Método pode terminar, falhar ou provocar exceção6/4/2012 Eduardo R Carvalho 18
  19. 19. [TDD] – JUnit : Exemplo de Test Case package junitdemo; import junit.framework.*; import java.io.IOException; public class TextUtilsTest extends TestCase { public TextUtilsTest(String name) { super(name); } public void testRemoveWhiteSpaces() throws IOException { String testString = "one, ( two | three+) , " + "(((four+ |t five)?n n, six? "; String expectedString = "one,(two|three+) " + ",(((four+|five)?,six? "; String results = TextUtils.removeWhiteSpaces(testString); assertEquals(expectedString, results); } }6/4/2012 Eduardo R Carvalho 19
  20. 20. [TDD] – JUnit : Fazendo o Teste Passar 1. package junitdemo; 2. import java.io.*; 3. public class TextUtils { 4. public static String removeWhiteSpaces(String text) throws ...{ 5. return "one,(two|three+),(((four+|five)?,six?"; 6. } 7. }  O teste passa... e daí? A solução está pronta? Não! Tem dados duplicados! Remova-os!  Escreva um novo teste que faça com que esta solução falhe, por exemplo:  String test2 = " a bnc ";  assertEquals("abc", TextUtils.removeWhiteSpaces(test2));6/4/2012 Eduardo R Carvalho 20
  21. 21. [TDD] – JUnit : Fazendo o Teste Passar!! 1. package junitdemo; 2. import java.io.*; 3. public class TextUtils { 4. public static String removeWhiteSpaces(String text) 5. throws IOException { 6. StringReader reader = new StringReader(text); 7. StringBuffer buffer = new StringBuffer(text.length()); 8. int c; 9. while( (c = reader.read()) != -1) { 10. if (c == ||c ==n||c ==r|| c ==f||c ==t) { 11. ; /* do nothing */ 12. } else { 13. buffer.append((char)c); 14. } 15. } 16. return buffer.toString(); 17. } 18.}6/4/2012 Eduardo R Carvalho 21
  22. 22. [TDD] – JUnit : TestSuite  Permite executar uma coleção de testes  Método addTest(TestSuite) adiciona um teste na lista  Padrão de codificação (usando reflection):  retornar um TestSuite em cada test-case: 1. public static TestSuite suite() { 2. return new TestSuite(SuaClasseTest.class); 3. }  Criar uma classe AllTests que combina as suites: 1. public class AllTests { 2. public static Test suite() { 3. TestSuite testSuite = new TestSuite("Roda tudo"); 4. testSuite.addTest(pacote.AllTests.suite()); 5. testSuite.addTest(MinhaClasseTest.suite()); 6. testSuite.addTest(SuaClasseTest.suite()); 7. return testSuite; 8. } 9. }6/4/2012 Eduardo R Carvalho 22
  23. 23. [TDD] – JUnit : Fixture  São os dados reutilizados por vários testes 1. public class AttributeEnumerationTest extends TestCase { 2. String testString; String[] testArray; 3. AttributeEnumeration testEnum; 4. public void setUp() { 5. testString = "(alpha|beta|gamma)"; 6. testArray = new String[]{"alpha", "beta", "gamma"}; 7. testEnum = new AttributeEnumeration(testArray); 8. } 9. public void testGetNames() { 10. assertEquals(testEnum.getNames(), testArray); 11. } 12. public void testToString() { 13. assertEquals(testEnum.toString(), testString); 14. } 15. ....  Se os mesmos dados são usados em vários testes, inicialize-os no setUp() e faça a faxina no tearDown() (se necessário)  Não perca tempo pensando nisto antes. Escreva seus testes. Depois, se achar que há duplicação, monte o fixture.6/4/2012 Eduardo R Carvalho 23
  24. 24. [TDD] – JUnit : Testando a Falha !!!  É tão importante testar o cenário de falha do seu codigo quanto o sucesso  Método fail() provoca uma falha  Use para verificar se exceções ocorrem quando se espera que elas ocorram  Exemplo: 1. public void testEntityNotFoundException() { 2. resetEntityTable(); // no entities to resolve! 3. try { 4. // Following method call must cause exception! 5. ParameterEntityTag tag = parser.resolveEntity("bogus"); 6. fail("Should have caused EntityNotFoundException!"); 7. } catch (EntityNotFoundException e) { 8. // success: exception occurred as expected 9. } 10.}6/4/2012 Eduardo R Carvalho 24
  25. 25. [TDD] – JUnit : Resumo  Para o JUnit :  Um teste é um método  Um caso de teste é uma classe contendo uma coleção de testes (métodos que possuem assertions)  Cada teste testa o comportamento de uma unidade de código do objeto testado (pode ser um método, mas pode haver vários testes para o mesmo método ou um teste para todo o objeto)  Fixtures são os dados usados em testes  TestSuite é uma composição de casos de teste  Pode-se agrupar vários casos de teste em uma suite  JUnit testa apenas a interface das classes  Mantenha os casos de teste no mesmo diretório que as classes testadas para ter acesso a métodos package-private  Use padrões de nomenclatura: ClasseTest, AllTests  Use o Ant para separar as classes em um release6/4/2012 Eduardo R Carvalho 25
  26. 26. [TDD] – JUnit : NetBeans 6.7.x  http://junit.netbeans.org/proposed-new-features.html6/4/2012 Eduardo R Carvalho 26
  27. 27. [TDD] – JUnit 4 : Simple Test 1. public class DAOTest { 2. @BeforeClass 3. public static void setUpClass() throws Exception { } 4. @AfterClass 5. public static void tearDownClass() throws Exception {} 6. @Before 7. public void setUp() {} 8. @After 9. public void tearDown() {} 10. @Test 11. public void testXXX() { } 12. @Test 13. public void testYYY() { } 14.}6/4/2012 Eduardo R Carvalho 27
  28. 28. [TDD] – JUnit 4 : TestSuite 1. @RunWith(Suite.class) 2. @Suite.SuiteClasses( {br.com.fastbuy.dao.ItemDAOTest.class , 3. br.com.fastbuy.framework.dao.DAOHelperTest.class }) 4. public class SampleTestSuite { 5. @BeforeClass 6. public static void setUpClass() throws Exception {} 7. @AfterClass 8. public static void tearDownClass() throws Exception {} 9. @Before 10. public void setUp() throws Exception {} 11. @After 12. public void tearDown() throws Exception {} 13.}6/4/2012 Eduardo R Carvalho 28
  29. 29. [TDD] – Best Practices  JUnit facilita bastante a criação e execução de testes, mas elaborar bons testes exige mais  O que testar? Como saber se testes estão completos?  "Teste tudo o que pode falhar" [2]  Métodos triviais (get/set) não precisam ser testados.  E se houver uma rotina de validação no método set?  É melhor ter testes a mais que testes a menos  Escreva testes curtos (quebre testes maiores)  Use assertNotNull() (reduz drasticamente erros de NullPointerException difíceis de encontrar)  Reescreva seu código para que fique mais fácil de testar6/4/2012 Eduardo R Carvalho 29
  30. 30. [TDD] – Best Practices  Escreva listas de tarefas (to-do list)  Comece pelas mais simples e deixe os testes "realistas” para o final  Requerimentos, use-cases, diagramas UML: rescreva os requerimentos em termos de testes  Dados  Use apenas dados suficientes (não teste 10 condições se três forem suficientes)  Bugs revelam testes  Achou um bug? Não conserte sem antes escrever um teste que o pegue (se você não o fizer, ele volta)!  Teste sempre! Não escreva uma linha de código sem antes escrever um teste!6/4/2012 Eduardo R Carvalho 30
  31. 31. [TDD] – Test-Driven Development  Desenvolvimento guiado pelos testes  Só escreva código novo se um teste falhar  Refatore até que o teste funcione  Alternância: "red/green/refactor" - nunca passe mais de 10 minutos sem que a barra do JUnit fique verde.  Técnicas  "Fake It Til You Make It": faça um teste rodar simplesmente fazendo método retornar constante  Triangulação: abstraia o código apenas quando houver dois ou mais testes que esperam respostas diferentes  Implementação óbvia: se operações são simples, implemente-as e faça que os testes rodem6/4/2012 Eduardo R Carvalho 31
  32. 32. [TDD] – Como Lidar com Testes Difíceis  Testes devem ser simples e suficientes  XP: design mais simples que resolva o problema; sempre pode-se escrever novos testes, quando necessário  Não complique  Não teste o que é responsabilidade de outra classe/método  Assuma que outras classes e métodos funcionam  Testes difíceis (ou que parecem difíceis)  Aplicações gráficas: eventos, layouts, threads  Objetos inacessíveis, métodos privativos, Singletons  Objetos que dependem de outros objetos  Objetos cujo estado varia devido a fatores imprevisíveis  Soluções  Alterar o design da aplicação para facilitar os testes  Simular dependências usando proxies e stubs6/4/2012 Eduardo R Carvalho 32
  33. 33. [TDD] – Resumo  Testar é tarefa essencial do desenvolvimento de software.  Testar unidades de código durante o desenvolvimento é uma prática que traz inúmeros benefícios  Menos tempo de depuração (muito, muito menos!)  Melhor qualidade do software  Segurança para alterar o código  Usando TDD, melhores estimativas de prazo  JUnit é uma ferramenta open-source que ajuda a implementar testes em projetos Java  TDD ou Test-Driven Development é uma técnica onde os testes são usados para guiar o desenvolvimento  Ajuda a focar o desenvolvimento em seus objetivos  Mock objects ou stubs podem ser usados para representar dependência e diminuir as responsabilidades de testes6/4/2012 Eduardo R Carvalho 33

×