Estratégias para testes: a metáfora da pirâmide alimentar Jorge Diz Instrutor Globalcode Kleber Xavier Instrutor Globalcode 1
Agenda > O que são testes? > Tipos de testes > A pirâmide de testes (Huggins) > Testes antes, durante e depois > Testes de aplicativos web > Selenium > Fitnesse > Cactus > Conclusões 2
O que são testes? > Projeto e implementação de um sistema de software que exercita outro sistema com o intuito de encontrar bugs [Binder] 3
Tipos de testes > Muitas classificações, baseadas no objetivo > Teste unitário: classes e métodos > Teste de integração: interação entre classes > Teste funcional: funcionalidades, regras de negócio, casos de uso > Teste de carga: múltiplos usuários > Teste de interface: interface com usuário > Teste de aceitação: atende objetivos do usuário > O que testar então? 4
Pirâmide Alimentar 5
Pirâmide de testes (Huggins*) (*) Jason Huggins, autor do Selenium 6
Quando testar? > Escrever o teste depois: > O sistema compila, a entrega é amanhã: agora vamos testar > Grande torcida para o sistema funcionar > testes bondosos > testes exploratórios 7
Modelo V 8
Quando testar? > Modelo V: > Na hora do desenvolvimento, já estou vendido no escopo: testes são vistos apenas como um controle de qualidade > Feedback muito tardio > Especificação imatura dos testes 9
Quando testar? > Testar pouco: > Em processos de software: a qualidade que eu consigo seguindo o processo é tão boa que não preciso tanto de testes > Pense positivo! 10
Quando testar? > Teste como suporte ao desenvolvimento: > Test-driven, example-driven, behavior-driven. > Definição da forma de uso externo (API) de uma biblioteca > Feedback imediato > Exagero na importância da automação 11
O que estamos testando? > Regras de negócio teste FIT > Funcionalidade de componentes web Cactus (teste in-container) > Interface usuário Selenium (teste in-browser) > Estresse/desempenho JMeter 12
Teste de aplicativos web > Complicadores: > Disponibilizar (ou aproximar) o ambiente de servidor web > Dependência de configurações > Dependência de browsers > Dependência de JavaScript > AJAX / tempos de espera 13
Teste de UI para web > Opções: > Simular o browser HTMLUnit > Executar in-browser, em JavaScript Selenium Core > Acionar browser a partir de um programa em Java (ou C#, Ruby, etc) Selenium RC > Acionar browser a partir de um plugin do browser Selenium IDE > Acionar browser a partir de um wiki StoryTest IQ (Selenium + FitNesse) > Acionar browser a partir de um editor de workflow CubicTest (Selenium + plugin Eclipse) 14
Selenium - arquitetura Testes JUnit CubicTest plugin Eclipse IDE CubicTest StoryTest IQ Selenium On Rails Selenium RC Client API ( Java ) Selenium RC Client API ( Ruby ) * Selenium RC Server Java Selenium Core JavaScript DOM (X)HTML Browser: IE, Firefox, Safari,... Selenium IDE (só ( Firefox 15
Selenium para programadores > Ferramentas > Selenium RC Client API para Java, Ruby, Perl, C#, Python > Programação de testes via a RC API > Programação de testes em JavaScript no Selenium Core > Componentes do lado servidor para testes in-container (para AJAX) > Usos: > AJAX (componentes testáveis no servidor) > Testes em JavaScript > Lógica de testes com controle de fluxo, concorrência, massa de dados de teste. 16
Selenium: não programadores > Ferramentas > Selenium IDE > Story Test IQ > CubicTest > Selenium Grid > Usos: > Record & replay > Testes com vários browsers > Testes como especificação do fluxo da aplicação 17
Selenium IDE 18
Selenium IDE TestRunner 19
Story Test IQ 20
Cubic Test 21
Teste de regras de negócio > Testes de aceitação X testes unitários > construindo o código certo (aceitação/validação) > construindo certo o código (unitário/verificação) > Métrica RTF (Running, Tested Features) [Ron Jeffries] > número de funcionalidades entregues testadas e executando > Ferramenta FitNesse > ferramenta Wiki que pode ser utilizada por analistas de teste e de negócios > especificação de requisitos em planilhas > codificação de fixtures pode ser feita por programadores 22
Fitnesse - arquitetura diagrama extraído do site http://fitnesse.org 23
Fit planilha original 24
FitNesse tabela Wiki 25
FitNesse fixture package br.com.globalcode.aceitacao; import fit.columnfixture; import br.com.globalcode.impostos.rendanafonte; public class ImpostoDeRendaNaFonteFixture extends ColumnFixture{ public double salariobruto; public int dependentes; public double impostoretido() { return RendaNaFonte.desconto(salarioBruto); } } public double salarioliquido() { return RendaNaFonte.liquido(salarioBruto); } 26
FitNesse classe de negócio package br.com.globalcode.impostos; public class RendaNaFonte { public static double desconto(double bruto) { return bruto * 0.2; } } public static double liquido(double bruto) { return bruto * 0.8; } 27
FitNesse resultado 28
DSLs em planilhas FIT > DSL = domain-specific language > Linguagens específicas para um determinado domínio > Criadas caso-a-caso, aproveitam o motor do FIT > Podem ser implementadas utilizando fixtures customizadas (DoFixture) 29
Teste de componentes JavaEE > Fora do contêiner utilizando objetos que simulam os componentes gerenciados (mock objects) > Não é necessário executar o servidor de aplicações > Não é testada a interação do componente com o servidor no qual ele será instalado > Dentro do contêiner > são necessárias ferramentas específicas > configuração mais complexa > os ambientes são testados num ambiente mais próximo do real 30
Cactus > Ferramenta Cactus > framework para testes de componentes Java EE (Servlets, EJB, Filtros, tags customizados) > baseado na ferramenta JUnit > o teste executa parte no cliente e parte no servidor 31
Cactus diagrama extraído do site http://jakarta.apache.org/cactus 32
Cactus - arquitetura 1:beginX 1b <<new>> 2: () setup 3: () testx 4: () teardown MeuTestCase MeuTestCase 5: endx <<Servlet>> <<Servlet>> MeuTestCase beginxyz Proxy MeuTestCase Proxy setup* testxyz* setup setup teardown* testxyz testxyz endxyz teardown Container teardown Container JEE (Ex: JEE (Ex: Jetty Jetty Web Web ( Container ( Container (*) no servidor A classe de caso de teste é instanciada duas vezes pelo test runner Os métodos setup, testx e teardown executam dentro do container 33
Conclusões > características diferentes requerem diferentes tipos de testes > cada tipo de teste possui a sua ferramenta específica > conjunto de testes balanceado testes diferentes nas quantidades adequadas (pirâmide de testes) > Testes não são só para garantia de qualidade 34
Conclusões > Mitos: > Testador não precisa programar > Programador não precisa testar > Usuário não precisa definir testes > Vale a pena automatizar tudo > Ligar sempre os desconfiômetros 35
Perguntas e Respostas 36