Your SlideShare is downloading. ×
  • Like
Automatizando testes em 4 passos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Automatizando testes em 4 passos

  • 517 views
Published

Apresentação feita para a equipe da RBS sobre automatização de testes. Em quatro passos, verificamos qual a parte do nosso código que precisa mais atenção, e auxiliado por ferramentas ampliamos a …

Apresentação feita para a equipe da RBS sobre automatização de testes. Em quatro passos, verificamos qual a parte do nosso código que precisa mais atenção, e auxiliado por ferramentas ampliamos a confiabilidade dos códigos.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
517
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
10
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Automatizando em quatro passos TESTES @helmedeiros
  • 2. 1. Conhecimentos básicos de testes2. Cobertura de testes com Emma3. Desenvolvendo testes unitários com JUnit4. Testes unitários com objetos dubles usando mockito
  • 3. Conhecimentos básicos de testes
  • 4. quantomaiorestresse menor menor execução de testes Gerry Weinberg diagrama de influência
  • 5. valiar” ifica “a m maior ar sign em produção o estresse é b etest
  • 6. Top Down de aceitação... cenários de teste... critérios Bottom up box... 22 caixas de texto... 15 combo
  • 7. FIZuma mu dança QUEBROU UMA PARTE QUE NÃ DEVIA O TEST - Teste Isolado ISOLATED pida; deve ser rá 1.A execuçã o dos testes eve ignorar as demais; 2. A execução d e um teste d Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 8. alta éCOESÃO um módulo a medida da força relativa defraco ACOPLAMENTO módulos é o nível de interdependência entre os
  • 9. TESTEImeu código O que m ais deveria testar? - Lista de testes TEST LIST ue precisa im plementar; perações que você sabe q ista ex emplos das o erência nula; 1.Coloque na l coloque a ve rsão de conf ar o código. implementa das zer para limp 2 .Para todas já e você acha que terá de fa te todas as re fatorações qu 3.Lis Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 10. 1. Qual o conjunto de testes, que quando passarem, demonstrará que ocódigo que estamos confiantes que irá calcular o relatóriocorretamente? $5 + 10 CHF = $10 se a taxa é 2:1 $5 * 2 = $10 Tornar a “quantidade” privada Efeitos colaterais em Dollar? Arredondamento de dinheiro? Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 11. ESCREVImeu código QUANDO EU DEVO ESCREVER MEUS TESTES? RST - Teste primeiro TEST FI .Primeiro escreva os testes; ontrolado; 1 e designe c a o código c om o escopo 2.D epois escrev Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 12. ESCREVImeu teste COMO EU FOCO A FUNCIONALI TESTE ? DADE E NÃO NO serção primeiro ST - Defina a as ASSERT FIR ando o código estiver certo; a a asserção q ue passará qu 1.Pr imeiro escrev pendências; lva de baixo p ara cima as de 2.Depois reso Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 13. Quando eu testo definindo uma asserção primeiro, defino comoreversa a minha lógica de construção, resolvendo um problema porvez. De onde a resposta vem? Do socket, certamente:Quando pronto o socket deve estar fechado e deveríamos 2 ter lido a string abc1 Mas, antes disso, precisamos abrir o servidor: E o socket? Nós o criamos conectando ao servidor: 3 4 Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 14. ESCREVImeu teste A ORDEM DOS PARÂMETROS IMPORTA? TA - Dados de teste TEST DA stes fáceis de ler e seguir; dados que faça m os te ença use dado s diferentes; 1.Use etros de cham ada fizer difer 2.Quando a or dem dos parâm Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 15. ESCREVImeu teste O QUE SIGNIFICA NO SEGUNDO PARÂMETRO O VALOR 3? TA - Dados evidentes EVIDENT DA m qual o objet ivo do dado; 1.Pense e te objetivo; constante que transpareça es 2.Defina uma vezes para cas os diferentes. ilize a mesma constante duas *Não ut Kent Beck TDD - Desenvolvimento Guiado por Testes
  • 16. Todos os parâmetros de um método devem ser claros enquanto assuas intenções, assim como deve ser sua utilização. Devemos SEMPREevidenciar o objetivo de cada valor. Constantes com o mesmo valor são diferidas pelo nome da constante.1 O nome da constante diferencia os significados/intenções de cada parâmetro dentro da requisição e por conseguinte as cenário de teste. 2 Caelum FJ-16: Laboratório Java com Testes, XML
  • 17. TDD ento guiado por testesDesenvolvim 1 quais as soluções para o problema? qual o primeiro cenário que desejo resolver? 2 n++ 3 qual o próximo cenário? RESOLVIDO X
  • 18. er um prob lema escolh m teste que fa lhe!escrever ured
  • 19. rápido possível! le passar o maisfazer e green
  • 20. r que está bom! fatorar até achadepois re yello
  • 21. NOSSO PROBLEMA FizzBuzz
  • 22. 1 2 Fizz { 4 Buzz dada uma Fizzlista de 1 a 100 7 múltiplos de 3 8 múltiplos de 5 Fizz múltiplos de 3 e 5 Buzz 11 Fizz 13 14 FizzBuzz
  • 23. Cobertura de testes com Emma
  • 24. veragetest cocobertura de testes é qualquer medida de abrangência relacionada a um requisito ou a um critério de design/implementação do código, como a verificação de casos de uso ou execução de todas as linhas de código.
  • 25. ENCONTRAR código não testado veragetest co cobertur a de test es GARANTIR X qualidade do código
  • 26. statement coverage se detêm ao simples registro sobre quais linhas foram executadas.multiple conditions coverage mede cada condição lógica no código avaliando se existem cenários não testados.
  • 27. código original Instrumentação código avaliadomultiple conditions coverage mede cada condição lógica no código avaliando se existem cenários não testados. execução dos testes
  • 28. Instrumentação A ferramenta de cobertura modifica o código para registrar quais expressões avaliar em qual caminho. Esta modificação pode ser feita tanto para o código-fonte quanto para o executável que o compilador gera. Se for feito de código-fonte, a maioria das ferramentas não alteram a fonte original, em vez disso, eles modificam uma cópia que é então passada para o compilador de uma maneira que faz parecer que é o original.multiple conditions coverage mede cada condição lógica no código avaliando se existem cenários não testados. Após a instrumentação, você deve executar vários testes, acumulando resultados de cobertura em alguns log.
  • 29. Códigos com condições lógicas são instrumentados, e após a execuçãosão apresentados logs que descrevem dentre as possíveis condiçõesquais não foram testadas. Código limpo, com condições lógicas: Código testado, com diferentes logs para as condições lógicas: 1 2 multiple conditions coverage mede cada condição lógica no código avaliando se existem cenários não testados.
  • 30. EclEMMA para o Eclipse. ferramenta de cobertura de código JaCoCode cobertura de código para Java.JaCoCo é uma biblioteca livre
  • 31. A execução de testes e cobertura não devem ser deixado para a fase debuild e deploy, nem muito menos serem restritas as ferramentas decontinuous deployment, todo desenvolvedor deve ser capaz deexecutar quantas vezes necessário antes de comitar seu código. EclEMMA 1 2 3
  • 32. Cada execução da bateria de testes e cobertura de seu código realizadapelo eclipse lhe conduzirá a um novo cenário de testes. Para cadacenário avalie o resultado esperado e crie um novo teste paraaumentar a cobertura sob o aspecto. 2 1EclEMMA Execute a bateria de testes de cobertura apertando no nome do O que o seu código devera fazer? método ou da classe. Liste os cenários e em seguida as asserções para cada um destes. Analise o relatório e veja oque ainda falta ser avaliado. 3
  • 33. Scripts de execução de testes e de cobertura são abstrações menores, edesta forma devem ser preferíveis a grandes alterações ou escolhasestruturais. O JaCoCo e o Emma são excelentes e enxutas bibliotecaspara execução na maquina dos desenvolvedores e serviços de deploy. 1 Criar targets para executar testes no junit, com apontamentos para os arquivos do emma. JaCoCo 3 2 Criar target para criação dos reports baseados nos arquivos gerados após a execução dos Criar target para execução da testes. instrumentação pelo emma.
  • 34. A execução de testes e cobertura devem ser repetidos na fase de builde deploy, com o apoio das ferramentas de continuous deployment,todo membro da equipe deve saber como está a qualidade e aconfiança no código entregue com métricas acionáveis, acessíveis eauditáveis. JaCoCo
  • 35. A execução de testes e cobertura devem ser repetidos na fase de builde deploy, com o apoio das ferramentas de continuous deployment,todo membro da equipe deve saber como está a qualidade e aconfiança no código entregue com métricas acionáveis, acessíveis eauditáveis. Gráficos de cobertura de testes, especificos por build, detalhados em pacotes. JaCoCo
  • 36. NOSSO PROBLEMA FizzBuzz ESTES) (COBERTUR A DE T
  • 37. 1 2 Fizz { 4 Buzz dada uma Fizzlista de 1 a 100 7 múltiplos de 3 8 múltiplos de 5 Fizz múltiplos de 3 e 5 Buzz 11 Fizz 13 14 FizzBuzz
  • 38. Desenvolvendo testes unitários com JUnit
  • 39. itário este un re uma classeT apenas sob Um teste de unitário é um pedaço de código (normalmente uma classe) que chama um outro pedaço de código e verifica a exatidão de alguns pressupostos. Se os pressupostos estiverem errados, o teste de unidade falha.
  • 40. Relatório X sucessos teste fixture Y falhas Z erros teste unitário teste unitário test case test case test case executar teste fixture test case test case test case test case test case test case test case test case test case test case test case test case test case test case test case test runnerSuite de Teste executar
  • 41. JUnit este runner t O JUnit é um framework open-source, criado por Erich Gamma e Kent Beck, com suporte à criação de testes automatizados na linguagem de programação Java.
  • 42. A razão pela qual usamos testes em métodos ágeis é para quetenhamos especificações executáveis, adequadas sobre o que estásendo desenvolvido. Essas especificações devem falar sobre o que umaunidade faz, não sobre como ele executa suas tarefas. •assertEquals(expected, actual) •assertNotNull(Object object) •assertEquals(String message, expected, actual) •assertNotNull(String message, Object object) •assertSame(Object expected, Object actual) •assertTrue(String message, boolean condition) •assertSame(String message, Object expected, Object actual) •assertTrue(boolean condition) •assertNotSame(Object expected, Object actual) •assertFalse(String message, boolean condition) •assertNotSame(String message, Object expected, Object actual) •assertFalse(boolean condition) •assertNull(Object object) •fail() •assertNull(String message, Object object) •fail(String message)
  • 43. A elaboração dos cenários de teste envolvem a reflexão lógica, ou aevolução na forma de sincronizar fixtures que devem sersincronizados tendo em mente o ciclo de execução dos testes. @BeforeClass @Before TEST CASE @After @AfterClass @Before @AfterClass @BeforeClass @Ignore @After @Test(expected=...)
  • 44. Comumente um conjunto de testes unitários devem ser executados emconjunto, seja devido a considerações enquanto ao raio de danos queuma alteração possa causar ou sentido funcional. Para isso usamos asSuites de teste. 1 Crie uma JUnit Test Suite nomeando-a apropriadamente 3 Execute a suite de testes, e analise o conjunto dos relatórios. Suite de testes 2 Defina a estratégia de agrupamento e quais são as classes que fazem parte deste.
  • 45. Maior parte do tempo você estará criando objetos que supram eespecifiquem suas necessidades para seus casos de teste. Quandoacontecer utilize Builders|ObjectMother como formas de especificarapenas o necessário. fixtures 1 2 3 Utilize os builders para tornar Crie uma JUnit Test Suite Crie uma classe Builder para seu mais legível cada uma das nomeando-a apropriadamente objeto. opções.
  • 46. “Métodos estáticos dificultam a escrita de testes de unidade. Para resolver isso podemos: evitar a escrita de métodos estáticos, ou criar abstrações que escondem esses métodos. Nao é feio criar abstrações como a Relogio; feio é não testar!” http://www.aniche.com.br/ 1 2 encontre locais onde você utiliza Defina uma interface a ser métodos estáticos que precisam utilizada no sistema em seu lugar ser simulados para seus casos de teste. testando métodos estáticos 4 Injete o objeto com o 3 comportamento que retorne como hoje o valor desejado Declare o campo em sua classe e em seguida substitua o mesmo pelas antigas chamadas estáticas.http://www.aniche.com.br/2011/09/testando-datas-e-metodos-estaticos/
  • 47. Um erro sem mensagem, ou sem referencias aninhadas pode ser umapedra no sapato. Desta forma tratar exceções na maior parte das vezesdeve estar relacionada as mensagens retornadas, assim como o tipo deerro. 1 encontre locais onde você utiliza métodos estáticos que precisam ser simulados para seus casos de teste. tratando exceções 2 Defina apenas a exceção esperada no bloco try catch. Manter throw da exceção recebida. E adicionar assert para mensagem.
  • 48. NOSSO PROBLEMA Frutas ctMother) uilders e Obje (JUnit, B
  • 49. Testes unitários com objetos dubles usando mockito
  • 50. ubmmy Dbofake e dules Test s, mocks, stu Muitas vezes objetos sob teste dependem de outros objetos, sobre os quais não temos nenhum controle (as vezes nem funcionam ainda). Neste caso usamos os dublês de teste, quaisquer objetos falsos, utilizado no lugar de um objeto real, com propósitos de teste.“There is no object-oriented problem that cannot be solved by adding a layer of indirection, except, of course, too many layers of indirection.”
  • 51. stub não quebram teste quando não chamados.objetos que possuem respostas pré-configuradas, mockquando não chamados. objetos que esperam ser acionados de uma forma específica, falham
  • 52. Muitas vezes, precisamos que nossa classe de teste se comporte de umadeterminada maneira, com pontos de verificação temporários, ouainda com uma implementação que não faz sentido em produção.Durante os testes usará acesso ao filesystem ao invés de base de dados. 1 2 Devemos criar uma interface para quando verificarmos um objeto a ser testado, ou o mesmo e substituí-lo por sua comportamento, apenas de estado. stubs auxiliar que não necessitar uma verificação de implementação. 3 Criar uma implementação com o comportamento desejado, e esperado.
  • 53. Muitas vezes precisamos verificar o comportamento de um objetoprincipal ou auxiliar em uma dada funcionalidade. Para estes casos omais indicado é a utilização dos MOCKS.1 mocks quando verificarmos um objeto a ser testado, ou auxiliar que necessitar uma verificação de comportamento. Devemos criar um mock para o mesmo. 23 Devemos verificar o comportamento do mesmo.
  • 54. Mockito é um framework de mocking, que permite escrever testesbonitos com API limpa e simples. •Cria Mocks de classes concretas assim como interfaces; •Anotações com syntax sugar; (@Mock) •Verificação dos erros é simplificada; •Suporta a verificação do exato numero assim como no mínimo um acesso de método; •Possuí verificação ou stub simplificado e flexível com utilização de matchers (anyObject(), anyString() ou refEq()); •Permite a criação de matchers customizados para argumentos usando hamcrest;