Intercon Android - Repensando as técnicas para qualidade no ecossistema Android
-
Upload
concrete-solutions -
Category
Technology
-
view
115 -
download
0
description
Transcript of Intercon Android - Repensando as técnicas para qualidade no ecossistema Android
Repensando as técnicas paraqualidade no
ecossistema Android
Jorge Diz
Agenda
Tecnologia / negócio / testes / arquitetura ● De onde viemos ?● Onde estamos ?● Para onde vamos ?
Meu Deus, isto fala!
Meu Deus, isto roda aplicativos !
Modelo V
Verificação
Inspeções Testes “dinâmicos”
Valida
ção
ExecutávelExecutável
Quadrantes de Marick
Negócio
Tecnologia
Suporte
TecnologiaTecnologia
Crítica ++ a
utom
ação
aut
omaç
ão --
Unidade
Regras
UI
SegurançaDesempenho
Usabilidade
Pirâmide de Cohn
UI
Unidades
Serviços
Ciclo de vida dos bugs
Diagnóstico
Defeito
Correção
Falha
Erro
Análise
Definições
● Erro = vacilo● Defeito = problema que ficou no sistema● Falha = sintoma● Diagnóstico = explicação● Análise = o quê vamos fazer ?● Correção = ação
Teste
● = Fazer defeito virar falha
(Intencionalmente)● Não necessariamente automatizado● Não necessariamente roteirizado● Não necessariamente contra uma
especificação
Monitoramento
● Analytics– Google Analytics / GTM
– Crashlytics
– NewRelic
– ...
● ~ teste contínuo → pode fazer defeito virar falha, na operação normal do app (ou api)
Cobertura
● Qual proporção do produto / serviço é testada● X % em cima de quê ?
– Classes. métodos, caminhos, parâmetros do app ?
– Execuções do app
– Modelos, configurações, localização
Em qual velocidade sua roda gira?
Diagnóstico
Defeito
Correção
Falha
Erro
Análise
TDD
● Desenvolvimento guiado por testes● Para desenvolvedores – mesma linguagem que o
código de produção● Modelo <X>unit, <X=linguagem> ● Depende de feedback muito rápido● Depende de dublês de teste (mocks, stubs)● Depende de arquitetura limpa
=> Difícil no ecossistema Android
ATDD
● Desenvolvimento guiado por testes de aceitação
● Feedback pode ser um pouco mais demorado (minutos)
● A maioria usa com UI
BDD
● Desenvolvimento guiado por comportamento● Conjunto de convenções e ferramentas para
ATDD● Sequestrado pelos desenvolvedores
O quê muda em Android?
● Arquitetura não facilita muito● Prazos ainda mais curtos● Escala● Quem vai usar precisa ser convencido● Menos controle sobre serviços / ambientes
utilizados pela solução (não é só o app)
Arquitetura: pecados originais
● Componentes baseados em herança● Activity não segue o SRP● Passos para construir o app são lentos● Não favorece TDD● Ciclo de vida idiossincrático● Reflexão / injeção (quase) só em tempo de
compilação● Builds muito lentas
Android Test Framework
● Teste de instrumentação – caixa branca● Baseado em JUnit 3.x● Inclui “mocks” (de fato, stubs) dos
componentes● Robotium → mais simples● Espresso → mais robusto
UI Automator
● Agente no Android, não depende da APK● Baseado em API de acessibilidade (a partir da API 16)● Fornece um serviço acessível remotamente – caixa
preta – viabiliza agentes + clientes em qualquer linguagem, BDD
● Agentes:– Calabash
– Appium
– Selendroid
Testes remotos de UI
● Dependem de agente no android● Cliente roda no PC, em qualquer linguagem● Alguns precisam alterar a aplicação● Appium (UIAutomator, WebDriver)● Calabash (protocolo próprio)● Selendroid (WebDriver)
Robolectric
● Roda em ambiente PC, não usa o aparelho● Roda na JVM, cria implementações alternativas
aos stubs gerados.● Busca viabizar testes rápidos, pode usar JUnit4