Como parte do desafio proposto pelo Vanilton lá no Agile Testers, resolvi escrever um pequeno post sobre a minha experiência com o Sikuli em um aplicativo mobile. A ideia não é ser um tutorial, mas tentarei passar alguns insights que tive ao me deparar com os desafios do projeto. Isso foi há quase 2 anos.

O Jogo

O aplicativo em questão era um jogo desenvolvido para a plataforma Tizen, o sistema operacional mobile da Samsung. Apesar de já ter superado o BlackBerry em market share no ano passado, o Tizen ainda é um ilustre desconhecido para a grande maioria de nós.

O jogo era uma versão para dispositivos móveis do famoso brinquedo Simon, um jogo de memória inventado em 1978 por Ralph H. Baer e Howard J. Morrison, com o desenvolvimento do software a cargo de Lenny Cope. Aqui no Brasil foi conhecido como Genius.

Para quem não viveu a época de ouro que foram os anos 80, o vídeo abaixo mostra um pouco do game play.

A Missão

Voltando ao projeto, a missão era simples: automatizar o jogo 😆 .

Nesse ponto, alguns já poderiam começar a se questionar: automatizar um jogo? Qual o sentido disso?

Sem querer entrar muito no mérito da questão, a necessidade veio da própria natureza do projeto: a não ser que você seja um prodígio da memória, é muito difícil memorizar sequências longas. Além disso, repetir o teste inúmeras vezes seria cansativo e maçante.

Sendo em Tizen, já era de se esperar a escassez de ferramentas de automação. Na época, cheguei a usar o excelente fmBT (Free Model Based Tool), mas esse não foi capaz de suprir todas as minhas necessidades. Então entra em cena o Sikuli.

Usando a ferramenta de captura do Windows foi possível recortar todos os ícones, botões e demais elementos gráficos do aplicativo. Portanto, considerando a aplicação instalada no emulador do Tizen, foi possível iniciá-la automaticamente por meio do Sikuli.

Dentre os recortes, destaco os dos botões:

Na fase de captura da sequência, precisei me concentrar nos botões iluminados. Eles que indicam o pressionamento de uma cor. No momento em que a sequência for reproduzida, o foco é nos botões não-iluminados. Para cada botão “on“, defini um padrão de similaridade.

Isso vai nos ajudar a verificar se esse recorte existe dentro uma imagem maior. Nesse caso, a imagem maior é um screenshot no momento exato em que o aplicativo seleciona uma cor e a acende. O ajuste na similaridade previne equívocos na hora do Sikuli encontrar uma determinada imagem. Para mais detalhes do Sikuli veja a série de posts no link.

A classe Robot do Java captura nosso screenshot.

Usei um contador no nome do arquivo para ter controle sobre cada screenshot, mas acredito que o nome poderia ser único.

Para localizar uma imagem contida em outra, é utilizado a classe Finder do Sikuli. Para procurar o recorte do botão vermelho dentro do screenshot, fiz uso do meu objeto definido lá no começo.

Se a cor é encontrada, já adiciono seu código a um ArrayList (chamado aqui de “sequence”). Dessa forma, poderei repetir a sequência mais tarde.

Como a sequência é gradual, isto é, na primeira passagem o aplicativo me desafia com uma cor, a qual devo repeti-la; na segunda passagem, são duas cores e assim sucessivamente, é só colocar tudo dentro de um loop.

A repetição da sequência é igualmente simples. Nesse caso, baseado no ArrayList, o botão vermelho que está apagado é clicado. O trecho de código para as outras cores é idêntico.

Dessa forma, mesmo nas sequências mais longas, o Sikuli foi capaz de reproduzi-las com maestria.