Introdução a Programação Orientada a testes

882 visualizações

Publicada em

Introdução a ferramentas de teste automatizados. Junit, Mockito, Hamcrest, Selenium, DbUnit e Spring-test

Publicada em: Software
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
882
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
16
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Introdução a Programação Orientada a testes

  1. 1. Programação Orientada a Testes André Luiz Forchesatto
  2. 2. Ementário ● Compreender as técnicas para teste de software através da utilização de ferramentas de testes automatizados. Avaliação de qualidade do código e cobertura de testes utilizando ferramentas automatizadas.
  3. 3. POG POF XGH
  4. 4. POG POF XGH
  5. 5. Testes de Software ● A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro ● Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto ● Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.
  6. 6. Testes de Software ● Se erros facilmente corrigíveis forem encontrados a qualidade e a confiabilidade do software estão aceitáveis ou os testes são inadequados para revelar erros graves ● Se não for encontrado erro a configuração de teste não foi suficientemente elaborada e erros estão escondidos no software
  7. 7. Testes de Software ● Projetar testes que descubram sistematicamente diferentes classes de erros e façam-no com uma quantidade de tempo e esforço mínimos. ● Se erros graves forem encontrados com regularidade a qualidade e a confiabilidade de software são suspeitas.
  8. 8. Etapas para atividade de testes Fonte: http://pt.slideshare.net/FabricioFFC/introduo-ao-teste-de-software-uma-abordagem-prtica
  9. 9. O que Testar? ● Normal ISO/IEC 9126/1991 ou NBR 13596 Fonte: http://pt.slideshare.net/FabricioFFC/introduo-ao-teste-de-software-uma-abordagem-prtica
  10. 10. Dependerá do tipo de software Fonte: http://pt.slideshare.net/FabricioFFC/introduo-ao-teste-de-software-uma-abordagem-prtica
  11. 11. Projeto de casos de teste Métodos de Projeto de Casos de Teste oferecem uma abordagem sistemática ao teste e um mecanismo que ajuda a garantir a mais alta probabilidade de revelar erros no software com uma quantidade mínima de tempo e esforço. Utilizado para códigos já existentes. ABORDAGENS de TESTE: 1. Teste de Caixa Preta 2. Teste de Caixa Branca
  12. 12. Teste Caixa Preta ● Refere-se aos testes que são realizados nas interfaces do software. ● São usados para demonstrar que as funções dos softwares são operacionais, que a entrada é adequadamente aceita e a saída é corretamente produzida; ● Verifica se a integridade das informações externas é mantida ● Examina aspectos do sistema sem se preocupar muito com a estrutura lógica interna do software.
  13. 13. Teste Caixa Preta ● Concentram-se nos requisitos funcionais do software. 1) funções incorretas ou ausentes 2) erros de interface 3) erros nas estruturas de dados ou no acesso a bancos de dados externos 4) erros de desempenho 5) erros de inicialização e término
  14. 14. Teste Caixa Branca ● Baseia-se num minucioso exame dos detalhes procedimentais ● "Status do programa" pode ser examinado em vários pontos para determinar se o status esperado ou estabelecido corresponde ao status real ● São testados os caminhos lógicos através do software, fornecendo-se casos de teste que põem à prova conjuntos específicos de condições e/ou laços
  15. 15. Teste Caixa Branca ● Um teste de Caixa Branca efetuado de forma muito cuidadosa levaria a "100% de programas corretos" ? ● Testes exaustivos apresentam certos problemas logísticos. Mesmo para pequenos programas, o número de caminhos lógicos possíveis pode ser muito grande. ● É um método de projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos de teste.
  16. 16. Teste Caixa Branca ● Podem ser derivados casos de teste que: ○ garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez. ○ exercitem todas as decisões lógicas para valores falsos ou verdadeiros. ○ executem todos os laços em suas fronteiras e dentro de seus limites operacionais. ○ exercitem as estruturas de dados internas para garantir a sua validade.
  17. 17. Teste Caixa Branca ● Teste de Caminho Básico: ○ O método de caminho básico possibilita que o projetista do caso de teste derive uma medida de complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução. ○ GRAFO DE FLUXO ou GRAFO DE PROGRAMA: uma notação para representar o fluxo de controle. Cada construção estruturada tem um símbolo de grafo correspondente.
  18. 18. Teste Caixa Branca
  19. 19. Teste Caixa Branca ● Caminho Independente: ○ Qualquer caminho através do programa que introduza pelo menos um novo conjunto de instruções de processamento ou uma nova condição.
  20. 20. 21 Conjunto Básico Caminho 1: 1-11 Caminho 2: 1-2-3-4-5-10-1-11 Caminho 3: 1-2-3-6-8-9-10-1-11 Caminho 4: 1-2-3-6-7-9-10-1-11 Teste Caixa Branca
  21. 21. 22 ● Complexidade Ciclomática ○ É uma métrica de software que proporciona uma medida quantitativa da complexidade lógica de um programa. ○ Define o número de caminhos independentes do conjunto básico de um programa e oferece um limite máximo para o número de testes que deve ser realizado para garantir que todas as instruções sejam executadas pelo menos uma vez. Teste de Caixa Branca Teste de Caminho Básico
  22. 22. 23 ● Complexidade Ciclomática ○ É computada numa das 3 formas seguintes: 1. o número de regiões do gráfico de fluxo 2. V(G) = E-N+2, onde E é o número de ramos do grafo e N o número de nós do grafo de fluxo G 3. V(G) = P+1, onde P é o número de nós predicativos (nós que contém uma condição) contidos no grafo de fluxo G Teste de Caixa Branca Teste de Caminho Básico
  23. 23. 24 Complexidade Ciclomática O grafo de fluxo tem 4 regiões V(G) = 11 ramos - 9 nós + 2 = 4 V(G) = 3 nós predicativos + 1 = 4 Complexidade Ciclomática do grafo de fluxo é 4. Grafo de Fluxo região1 região2 região3 região4 Ramos Nós Teste de Caixa Branca Teste de Caminho Básico
  24. 24. 25 O valor de V(G) oferece um limite máximo no número de testes que deve ser projetado e executado para garantir a cobertura de todas as instruções de programa. Teste de Caixa Branca Teste de Caminho Básico
  25. 25. 26 Derivando Caso de Testes - Passos do Método 1. Usando o projeto ou o código como base trace um grafo de fluxo correspondente Teste de Caixa Branca Teste de Caminho Básico
  26. 26. Teste de Caixa Branca Teste de Caminho Básico 4 8 1,2 3 7 5,6 9 10 Procedimento MAIOR(A:VETOR; T:inteiro; var MAX:inteiro); variáveis I,M:inteiro Inicio 1 M<- A[1]; 2 I<-2; 3 enquanto I < T faça 4 se A[I] > M 5 então M<- A[I] 6 I<- I+1 7 senão I<- I+1 8 fim se 9 fim enquanto 10 MAX<-M; fim do procedimento
  27. 27. 28 Derivando Caso de Testes - Passos do Método 2. Determine a Complexidade Ciclomática do grafo de fluxo resultante Teste de Caixa Branca Teste de Caminho Básico
  28. 28. 29 Complexidade Ciclomática 1. O grafo de fluxo tem 3 regiões 2. V(G) = 9 ramos - 8 nós + 2 = 3 3. V(G) = 2 nós predicativos + 1 = 3 A Complexidade Ciclomática é 3. 4 8 1,2 3 7 5,6 9 10 R2 R1 R3 Teste de Caixa Branca Teste de Caminho Básico
  29. 29. 30 Derivando Caso de Testes - Passos do Método 3. Determine um conjunto básico de caminhos linearmente independentes (3 caminhos) Teste de Caixa Branca Teste de Caminho Básico
  30. 30. 31 Teste de Caixa Branca Teste de Caminho Básico Caminhos Caminho 1: 1, 2, 3, 9, 10 Caminho 2: 1, 2, 3, 4, 5, 6, 8, 3, 9, 10 Caminho 3: 1, 2, 3, 4, 7, 8, 3, 9, 104 8 1,2 3 7 5,6 9 10 R2 R1 R3
  31. 31. 32 Derivando Caso de Testes - Passos do Método 4. Prepare os casos de teste que forcem a execução de cada caminho no conjunto básico. Teste de Caixa Branca Teste de Caminho Básico
  32. 32. Teste de Caixa Branca Teste de Caminho Básico Caminhos Caminho 1: 1, 2, 3, 9, 10 A=(1,3) T=0 Resultado Esperado => Max=1 Caminho 2: 1, 2, 3, 4, 5, 6, 8, 3, 9,10 A=(1,3) T=3 Resultado Esperado => Max=3 Caminho 3: 1, 2, 3, 4, 7, 8, 3, 9, 10 A=(3,1) T=3 Resultado Esperado => Max=3 Procedimento MAIOR(A:VETOR; T:inteiro; var MAX:inteiro); variáveis I,M:inteiro Inicio 1 M<- A[1]; 2 I<-2; 3 enquanto I < T faça 4 se A[I] > M 5 então M<- A[I] 6 I<- I+1 7 senão I<- I+1 8 fim se 9 fim enquanto 10 MAX<-M; fim do procedimento
  33. 33. Teste de Caixa Branca Ferramenta: EclEmma ● http://www.eclemma.org/ ● Plug-in do eclipse para métricas de teste, cobertura e complexidade. ● Pode ser instalado pelo Eclipse MarketPlace
  34. 34. Teste de Caixa Branca Ferramenta: EclEmma
  35. 35. Estratégias de Testes ● Teste de Unidade: É a verificação de um módulo único de programa isolado dos outros módulos. ● Teste de Integração: É a verificação das interfaces (comunicações) entre os módulos do sistema. ● Teste de Validação: É a verificação das funções do sistema conforme o que consta na sua especificação (requisitos do software). ● Teste de Sistema: É a verificação das funções do sistema no ambiente real, integrado com outros sistemas, conforme a definição do(s) usuário(s).
  36. 36. Ferramentas e frameworks para testes Ferramenta Finalidade JUnit, Hamcrest Teste unitário, automatiza a criação básica dos testes. Selenium Testes de aceitação, simula o comportamento do usuário utilizando o sistema. JMetter Teste de stress, simula uma quantidade de usuário para o sistema. Mockito Testes unitário, auxiliar na hora de isolar rotinas que não devem ser testadas. DBunit Teste de integração, popula bases de dados com informações de exemplo. Spring-test Teste de integração, auxiliar a construção dos testes que dependem do framework. SonarQube Ferramenta de análise de qualidade de código e cobertura de testes Jenkins Ferramenta para integração continua.
  37. 37. JUnit ● Junit é um framework que facilita o desenvolvimento e execução de testes ○ API para construção dos testes ○ Plugin e ferramentas para execução e visualização dos resultados ● API ○ Métodos: assertTrue(), assertEquals(), fail() entre outros, são responsáveis por verificar os resultados do teste ● Donwload ○ www.junit.org
  38. 38. Para que serve? ● 'Padrão' para testes de unidade em Java ○ Desenvolvido por Kent Beck (o guru do XP) e Erich Gamma (o G do GoF "Design Patterns") ○ Testar é bom 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 método de uma classe funciona da forma esperada ○ Permite agrupar e rodar vários testes ao mesmo tempo ○ Na falha, mostra a causa em cada teste
  39. 39. Como utilizar ● Criar uma classe de Test em seu projeto, e anotar os métodos com @Test import org.junit.Test; import static org.junit.Assert.*; public class AppTest{ @Test public void testSoma(){ App ap = new App(); assertEquals(new Float(10), ap.soma(5f, 5f)); } }
  40. 40. Como utilizar ... private Float valor1; private Float valor2; @Before public void setUp(){ valor1 = 5f; valor2 = 5f; } @After public void tearDown(){ //Libera recursos } ... Antes de iniciar cada método de teste Após execução de cada método de teste
  41. 41. Algumas checagens ● assertEquals ● assertArrayEquals ● fail ● assertFalse ● assertTrue ● assertNull ● assertNotNull ● assertThat
  42. 42. Uso das checagens Valor Esperado Valor Obtido
  43. 43. Hamcrest ● Frameworks que melhora a legibilidade dos testes. ● Simplifica a criação dos Asserts ● Retorna mensagens de falha mais legíveis ● https://code.google.com/p/hamcrest/wiki/Tutorial
  44. 44. Hamcrest fonte: http://blog.caelum.com.br/melhorando-a-legibilidade-dos-seus-testes-com-o-hamcrest/
  45. 45. Hamcrest - Matches ● Collections ○ array ○ hasEntry, hasKey, hasValue ○ hasItem, hasItems ○ hasItemInArray ● Object ○ equalTo ○ hasToString ○ instanceOf, isCompatibleType ○ notNullValue, nullValue
  46. 46. Hamcrest - Matches ● Number ○ closeTo ○ greaterThan, greaterThanOrEqualTo, lessThan, lessThanOrEqualTo ● Text ○ equalToIgnoringCase ○ equalToIgnoringWhiteSpace ○ containsString ○ endsWith ○ startsWith
  47. 47. Hamcrest - Matches ● Core ○ anything ○ describedAs ○ is ● Logical ○ allOf ○ anyOf ○ not
  48. 48. Hamcrest - Matches ● Matcher Personalizado: ○ Devemos extender de TypeSafeMatcher e passar o tipo do objeto a ser avaliado ○ Depois implementar os métodos: ■ void describeTo(Description desc) ■ boolean matchesSafely(T objeto)
  49. 49. Hamcrest - Matches fonte: http://blog.caelum.com.br/melhorando-a-legibilidade-dos-seus-testes-com-o-hamcrest/
  50. 50. Prática Criar projetos para exercitar os testes
  51. 51. TDD ● Test-Driven Development ● Desenvolvimento guiado pelos Testes ● Publicado pela primeira vez no livro TDD: By Example por Kent Beck em 2002 ● Uma das técnicas para receber feedback rápido
  52. 52. TDD - Vantagens ● Foco no teste e não na implementação ● Código nasce testado ● Simplicidade ● Melhor reflexão sobre o designer da classe
  53. 53. TDD
  54. 54. Prática Fazer exercício sugerido no livro Test-Driven Development da casa do código, página 21 capítulo 3.
  55. 55. Mock ● Objetos Dublês, ou objetos "falso" ● Simulam o comportamento das dependências
  56. 56. Mock ● Frameworks: ○ Mockito ○ jmockit ○ EasyMock ○ JMock ○ MockCreator ○ MockLib ○ HibernateMock
  57. 57. Mockito ● Framework open-source que auxilia na construção de Mocks ● Possui uma API fluente de fácil aprendizagem ● http://mockito.org/ ● https://github.com/mockito/mockito
  58. 58. Mockito ● @Mock ● @RunWith(MockitoJUnitRunner.class) ● when ● thenReturn ● thenReturn ● verify ● doReturn(Object) ● doThrow(Throwable) ● doThrow(Class) ● doAnswer(Answer) ● doNothing() ● doCallRealMethod() ● spy
  59. 59. Mockito
  60. 60. Prática Mockar objetos com Mockito
  61. 61. Testes de integração ● São testes que avaliam toda infra-estrutura do programa, desde a base de dados até os sistemas integrados; ● Geralmente levam muito mais tempo para serem executados; ● Frameworks úteis: ○ DBUnit ○ Spring-test
  62. 62. Spring-boot-test ● Simplifica o start dos testes de integração que dependem do contexto do Spring ● Já traz os frameworks Spring Test, JUnit, Hamcrest and Mockito com dependência <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency>
  63. 63. Classe de teste
  64. 64. Spring - Teste Integração web ● Simplifica através do MockMVC a comunicação com o Controller, simulando um requisição HTTP real.
  65. 65. Spring - Teste Integração web ● Simplifica a construção do teste, através de uma interface fluente
  66. 66. Prática Criar testes para aplicação web
  67. 67. DbUnit Teste Integração BD ● Framework para automatizar carga de base de dados ● Importa ou exporta dados para diferentes SGDB ● Se integra ao Spring ● http://dbunit.sourceforge.net/ ● http://springtestdbunit.github.io/spring-test-dbunit/
  68. 68. DbUnit Teste Integração BD ● Dependências <dependency> <groupId>com.github.springtestdbunit</groupId> <artifactId>spring-test-dbunit</artifactId> <version>1.1.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.dbunit</groupId> <artifactId>dbunit</artifactId> <version>2.5.0</version> <scope>test</scope> </dependency>
  69. 69. Spring-test + DBUnit ● Utiliza o mesmo dataSource que o Spring cria; ● Integração com o sistema de Transação e Listeners do Spring; @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class, DirtiesContextTestExecutionListener.class, TransactionalTestExecutionListener.class, DbUnitTestExecutionListener.class })
  70. 70. Spring-test + DBUnit ● @DatabaseSetup("sampleData.xml") ○ Inicializa a base de dados ● @DatabaseTearDown ○ Reseta a base de dados ● @ExpectedDatabase("expectedData.xml") ○ Resultado esperado após insert, update, delete
  71. 71. DBUnit - sample.xml <dataset> <tabela1 coluna1="valorcoluna1" coluna2="valorcoluna2"/> <tabela1 coluna1="valor2coluna1" coluna2="valor2coluna2"/> <tabela1 coluna1="valor3coluna1" coluna2="valor3coluna2"/> </dataset>
  72. 72. Prática Utilizar o DBUnit para popular uma base para testes.
  73. 73. Testes de aceitação - Selenium ● Conjunto de softwares diferentes para automatização de testes para web; ● Automatização do teste realizado pelo usuário; ● Avaliação com base nas tags HTML geradas pelo sistema;
  74. 74. Selenium fonte: http://pt.slideshare.net/hugs/selenium2mobilewebtesting
  75. 75. Vantagens Selenium ● Testes de regressão freqüente ● Feedback rápido para os desenvolvedores ● Iterações virtualmente ilimitado de execução do caso de teste ● Disciplinado documentação de casos de teste ● Relatórios defeito personalizado ● Encontrar defeitos perdidos por testes manuais
  76. 76. WebDriver ● É uma API orientada a objetos que facilita a construção de testes para páginas web; ● Provê comandos para navegar em páginas web, localizar e manipular elementos html. http://docs.seleniumhq.org/docs/03_webdriver.jsp Tutorial com lista de comandos: http://www.devmedia.com.br/introducao-aos- testes-funcionais-automatizados-com-junit-e-selenium-webdriver/28037
  77. 77. Comandos Comum ● get() ● findElement() ● click() ● submit() ● sendKeys() ● isDisplayed()
  78. 78. Localização de elementos ● class ● css seletor ● id ● xPath
  79. 79. Selenium - Download <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>2.45.0</version> </dependency>
  80. 80. Criando o Teste
  81. 81. Prática Criar sistema web e testes com Selenium.

×