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

Obrigado !

jorge.diz@concretesolutions.com.br

(estamos contratando na Concrete Solutions)