Em abril de 2022, houve uma release que deixou esse framework ainda mais incrível – principalmente se você curte desenvolver ‘à la’ TDD (Desenvolvimento Orientado a Testes):

Agora o AdonisJS possui suporte para testes automatizados!

Antes desta release, o AdonisJS já suportava integração com testes automatizados, mas o desenvolvedor precisava realizar instalações e configurações à parte. Havia até um artigo na seção Cookbooks da documentação explicando quais dependências instalar e como configurar tudo para executar os testes.

Mas agora isso é passado, porque desde abril de 2022, toda aplicação inicializada traz arquivos com configurações padrão para testes, e a documentação possui uma seção dedicada aos testes automatizados.

[adrotate banner=”4″]

Conforme consta na descrição da release mostrada na imagem acima, o framework utilizado para executar os testes é o Japa. Então, vamos falar um pouco sobre ele destacando algumas features e explicar como o AdonisJS o utiliza.

AdonisJS + Japa

O Japa é um framework para testes que se descreve como sendo API-first e Node-only. Ou seja, ele é focado em testes para desenvolvimento de API`s no ambiente backend NodeJS. Esse framework tem a vantagem de ser extensível – o desenvolvedor pode instalar alguns plugins de acordo com as necessidades do projeto e até mesmo estender classes pré-existentes para atender às necessidades do projeto.

O Japa pode ser utilizado em qualquer projeto com NodeJS. Para isso, basta seguir as orientações de instalação e configuração da documentação (que também é de qualidade). Porém, ao criar um projeto AdonisJS, o desenvolvedor observará os seguintes arquivos-padrão:

tests/bootstrap.ts

Este arquivo armazenado dentro do diretório tests contém uma série de configurações que irão reger o processo de escrita e execução dos testes. Por exemplo, aqui cada desenvolvedor deve escolher quais plugins (suportados pelo Japa) serão utilizados durante os testes.

assert()

O Japa proporciona a liberdade de escolher plugins para escrever os testes utilizando a sintaxe de acordo com a preferência do desenvolvedor. Para aqueles que preferem usar a sintaxe do Chai (Assert), o Adonis adiciona o plugin assert() por padrão ao array plugins. Entretanto, se alguém optar pela sintaxe Jest, basta trocar o plugin por expect().

runFailedTests()

Outro plugin que vem definido por padrão é o runFailedTests(). Qual a sua função? Imagine que você escreveu 10 testes até o momento e os executou pela primeira vez.

Nessa primeira execução, dois testes falharam. Então, você faz alguns ajustes no código de produção e executa os testes pela segunda vez. Se runFailedTests() estiver no array de plugins, o Japa irá executar apenas os dois testes que falharam anteriormente. Caso desejar sempre executar todos os testes, basta remover o plugin do array.

apiClient()

Para testar os endpoints de uma API, o Japa oferece o plugin apiClient() – uma API completa, com inúmeras funções para simular requisições HTTP. É possível simular rotas protegidas por autenticação, rotas que esperam receber dados de um formulário, upload de arquivos, dados em JSON e muito mais. Vale a pena se familiarizar com esse plugin!

specReporter()

Também dentro do arquivo bootstrap.ts, mas desta vez dentro do array reporters, há um plugin do Japa chamado specReporter() registrado por padrão. Ele é responsável por apresentar, no terminal, informações detalhadas sobre o progresso e os resultados dos testes.

Esse plugin deve ser mantido! Se ele for retirado, não haverá nenhum erro de execução. Porém, também existirá nenhuma informação relacionada aos testes será exibida no terminal – a não ser uma mensagem padrão proveniente do Logger do AdonisJS.

runnerHooks

Logo abaixo das configurações de reporters, existe um objeto chamado runnerHooks, que possui duas propriedades: a primeira é um array – setup, e a segunda também é um array – teardown.

Toda função adicionada ao array setup será executada antes de todos os testes iniciarem. Aqui pode ser interessante registrar a execução de migrations e seeders para o banco de dados ou a inicialização de um servidor HTTP, por exemplo. Já as funções contidas no array teardown serão chamadas somente após todos os testes executarem.

Aqui, podem ser registradas funções que limpam alterações sofridas pelo banco de dados durante os testes, por exemplo.

configureSuite

Por último, existe uma função chamada configureSuite – o local onde a documentação sugere o registro hooks para conjuntos (suites) específicos de testes. No exemplo abaixo, o servidor HTTP é iniciado apenas antes de o conjunto de testes funcionais ser executado.

test.ts

Algo interessante de se notar é que todos os elementos (arrays, objetos e função) de configurações definidos no arquivo bootstrap.ts são exportados. Isso porque todos eles são importados pelo arquivo test.ts, que está no diretório raiz do projeto.

Este arquivo carrega todas as configurações necessárias para iniciar a aplicação AdonisJS e executar os testes por meio do Japa, aplicando tudo o que definido no arquivo bootstrap.ts.

A própria documentação declara que raramente é necessário alterar esse arquivo. Dessa forma, tudo está pronto! Basta executar o comando $ node ace test para os testes iniciarem e o seguinte resultado aparecerá no terminal:

.adonisrc.json

Este arquivo é responsável por diversas configurações do AdonisJS, mas será dado destaque apenas à parte que rege os testes automatizados. Nessa parte do arquivo é possível separar os testes da aplicação em grupos chamados suites, o que é útil para deixar o projeto bem organizado. Dentro do array suites, o desenvolvedor pode inserir objetos com as propriedades:

• name (identificação do conjunto de testes);
• files (array com paths relativos para executar arquivos específicos);
• e o timeout (tempo máximo permitido para executar os testes).

É claro que começar a escrever os testes a partir de uma aplicação recém criada é relativamente fácil. Mas o que dizer sobre os projetos AdonisJS iniciados antes do release em abril de 2022? E se adicionar testes automatizados a um desses projetos mais antigos, nos quais não havia arquivos para configuração de testes por padrão?

Adicionando testes a projetos antigos

Como mencionado no início do artigo, o AdonisJS possui uma documentação bem abrangente. Por isso, não é de se surpreender que um passo a passo para integrar testes automatizados a projetos anteriores ao release de abril de 2022 esteja disponível neste link.

Esse breve tutorial oficial orienta o desenvolvedor a seguir os seguintes passos:

1. Atualizar dependências do projeto que sejam relacionadas ao AdonisJS:

Todo pacote registrado no arquivo package.json que contenha @adonisjs em seu nome (ex:@adonisjs/lucid) precisa ser atualizado. Atualizar todas as dependências de um projeto de uma só vez pode ser perigoso, gerando problemas no funcionamento da aplicação.

Por isso, pode ser interessante usar o gerenciador de pacotes Yarn, que oferece a solução de atualizar dependências de forma interativa por meio do comando $ yarn upgradeinteractive --latest. Assim, é possível atualizar apenas o necessário, sempre tomando cuidado com pacotes que contenham breaking changes, marcadas em vermelho:

2. Executar o comando node ace generate:manifest:

Este comando atualizará o arquivo ace-manifest.json, adicionando os comandos mais recentes da CLI utilizada pelo AdonisJS ao projeto.

3. Executar o comando node ace configure tests:

Neste passo, todos os arquivos de configuração necessários para executar os testes serão criados (os mesmos mencionados anteriormente), além de um teste-modelo pronto para ser executado.

4. Mudar nomenclatura do ambiente de teste testing para test:

Por último, é necessário mudar o nome dado pelo AdonisJS ao ambiente de testes. Geralmente, apenas no arquivo env.ts é necessário aplicar essa mudança ao enum da propriedade NODE_ENV.

Porém, alguns projetos possuem o arquivo config/shield.ts, no qual o ambiente de testes também está nomeado como testing, exigindo a mudança para test.

Com isso, tudo está pronto para começar a escrever os testes e executá-los!

Conclusão

De fato, AdonisJS e Japa formam uma dupla poderosa que pode turbinar o processo de desenvolvimento orientado a testes automatizados. Ambos possuem documentações completas e assertivas.

O Japa proporciona liberdade para escolher a sintaxe dos testes e disponibiliza plugins poderosos, enquanto o AdonisJS carrega diversas funcionalidades nativas para validação, autenticação, ORM e muitas outras.

Conheça um pouco mais do universo de desenvolvimento com o AdonisJS com essa série de vídeos do Luber Manoel Fernandes Neto. E para aprender muito mais sobre tecnologia, fique ligado no blog da Luby!

Autor: João Victor Pereira Rodrigues.

[adrotate banner=”5″]

Veja também:

Poised Testing – Tudo sobre o assunto.

Testes automatizados com React.

Desenvolvimento de Software.

O post Testes Automatizados com AdonisJS e Japa apareceu primeiro em Luby Software.

O método heurístico de representatividade é utilizado como base para criar e pensar nossos testes de API.

[adrotate banner=”4″]
O que é POISED?

Primeiramente, vamos dar uma olhada no que isso significa e como pode nos ajudar de fato! O significado das siglas de POISED Testing é:

• P – Parameters (Parâmetros);
• O – Outputs (Saídas);
• I – Interoperability (Interoperabilidade);
• S – Security (Segurança);
• E – Errors (Erros);
• D – Data (Dados).

O que cada uma dessas etapas significa?

Bom, visto que agora sabemos o que cada uma das letras de POISED Testing representa, vamos entender melhor a função de cada uma.

Parameters (Parâmetros)

Esta é a etapa em que você cria seus testes baseados nos parâmetros que a API a ser testada pode enviar. Isso pode funcionar tanto nos headers, parâmetros de URL e parâmetros no envio de dados, como o body de uma request com método POST.

Por exemplo:  

• Uma URL aceita ser enviado um header com um tipo de “content-type” x ,y,z e você envia um tipo não aceito;
• Uma URL precisa de um header específico para saber para qual parte da aplicação enviar e você não passa nesse header obrigatório;
• Um body de um request POST, para fazer um login num portal, precisa de campos obrigatórios e tipados por exemplo:

   		 {
	“email”: “” ,
	"password": 12345678
 }

Aqui você deveria ter passado um e-mail válido e passou uma string vazia. Além disso, na senha, deveria ter sido uma string e você passou um numérico qualquer.

Podemos ficar horas vendo tipos de parâmetros. Entretanto, com esses básicos já dá para entender e ir mais além do que seria o P desse modelo!

Outputs (Saídas)

Essa etapa será onde você criará seus testes baseados nas respostas das requests, validará se são coerentes, se estão corretas de acordo com o tipo de request e o status code recebido (response body x status code), logs feitos no console ou no servidor.

Por exemplo:

• Você envia uma requisição do método DELETE e recebeu status code 200 ou 204, mas no corpo da resposta recebeu “criado”;
• Você envia uma requisição do método POST e recebe um status code 200 e com o corpo da resposta vazio;
• Validar se os logs apresentados no console ou servidor são coerentes ou se possui o mínimo de informação relacionada.

Em tese, o Output é onde você cria seus testes para validar a coerência das respostas X o que foi requisitado.

Interoperability (Interoperabilidade)

Aqui é uma etapa muito importante, em que você cria testes para validar e checar a Interoperabilidade da comunicação das APIs, onde você cria testes de contrato, checa a idempotência da API, entre outros.

Além disso, nesta etapa, também pode ser pensado e criado testes de performance para entender qual a performance da sua API, quando muito exigida ou chamada por outros serviços ou outras APIs.

Por exemplo:

• Criar teste de contrato para, sempre que uma API precise, chamar os requisitos básicos e predefinidos como corretos, sendo atendidos e validados em seu comportamento. Por exemplo, o que uma API espera de parâmetros no body? Quais os tipos desses parâmetros? Quais as saídas? É importante não confundir com o teste de schema, onde é validado somente os tipos do schema.
• Validar a idempotência da API. Verificar se, mesmo ela sendo chamada n* x vezes por outra API ou outras, aquele comportamento esperado continua sendo o mesmo sempre.
• Criar testes de performance para latência e/ou saber o tempo de resposta de cada request depois de ter sido carregada com muitas requests.

Security (Segurança)

Uma das partes mais importantes do nosso modelo é criar testes e pensar estratégias de teste para cobrir possíveis cenários ou gaps de segurança na API. Por exemplo:

• Validar que, somente com informações corretas, você consegue chamar com sucesso os endpoints que precisam de autorização e autenticação, como tokens, cookies ou até mesmo senhas;
• Autenticar tempo de expiração das credenciais;
• Validar se é possível, por exemplo, ao invés de mandar a autenticação correta, você consegue mandar algum script de JavaScript no campo;
• Confirmar possíveis mensagens de respostas que contenham mais informação que o necessário ou logs que contenham informações internas, como logar o erro do banco de dados diretamente.

Errors (Erros)

Nesta etapa, podemos pensar sobre como validar as mensagens de erro (já vimos um pouco sobre isso nos tópicos Outputs e Security). Por exemplo:

• Pensar se estão de acordo com o contexto, requisição, ambiente e etc.;
• Verificar as mensagens de erro X o status code da resposta;
• Verificar se nos passam o real problema que aconteceu (pensando sempre na segurança, como dito acima).

Data (Dados)

Nesta fase, pensamos como validar os dados. Por exemplo:

• Validar as estruturas dos dados das requests, no body ou parâmetros;
• Validar os dados quando executamos alguma requisição que altere dados. Por exemplo, quando fazemos um delete, update ou created. Os dados foram corretamente atualizados ou deletados? Após as alterações, a estrutura continua a mesma? E por aí vai…

Pensando nisso, é importante lembrar:

• Precisamos sempre ter contato e conhecimento do código base para poder criar os testes com mais precisão e sempre com base na documentação;
• Além disso, é preciso checar também os testes unitários, para não cairmos no problema testes duplicados em camadas diferentes.

Conclusão

Passamos por um overview sobre o POISED Testing, para nos dar ideias e nos guiar quando pensarmos sobre criação de testes de API. Como falamos acima, este é um modelo heurístico que usamos para apoio.

Existem alguns outros modelos interessantes, segue aqui uma lista para você checar, se tiver interesse!

• VADER
• BINMEN

Autor: Francisco Antônio Navarro Moral.

[adrotate banner=”5″]

Leia também:

Bot Para testes: Como executar.

Testes automatizados com adonis JS.

O post POISED Testing: o que é e como utilizar? apareceu primeiro em Luby Software.

Neste artigo, vamos entender mais sobre os Testes de Performance NA PRÁTICA.

[adrotate banner=”4″]

O que são Testes de Performance?

O nome em si, muitas vezes, causa confusão na cabeça das pessoas. O conceito dos Testes de Performance engloba muitos sub-gêneros, iremos resumir em três mais utilizados. Em cada um deles, existe mais subtipos. Entretanto, neste artigo, iremos focar nestes que são a base para todos os outros.

Teste de Carga

O Teste de Carga é onde você “carrega” seu ambiente (pode ser um sistema inteiro, microsserviço, APIs, Brokers, etc) a ser testado com uma carga acima do seu workload atual durante um período. Assim, podendo também ir aumentando a carga durante um período. Entretanto, sempre dentro de um range aceitável para o seu contexto.

Teste de Stress

No Teste de Stress, você “carrega” seu ambiente a ser testado com uma carga muito acima do esperado para o seu contexto normal. Dessa forma, será possível entender como ele vai se comportar e se irá demonstrar falhas ou intermitências.

• Teste de “spike”, endurance, volume e escalabilidade são todos subgêneros com pequenas diferentes nuances para o de stress.

Chaos Teste

Como o próprio nome já diz, o Chaos Teste se trata de você avaliar e saber a partir de qual ponto seu ambiente a ser testado irá quebrar. Assim, poderá extrair métricas necessárias para as análises correspondentes (iremos falar mais sobre abaixo).

Configuração do Teste de Performance

Todos tipos de testes de performance possuem diferentes tipos de configuração de injeção. Então, iremos trazer abaixo alguns exemplos:

• Modelos de workloads abertos e fechados;

Aberto significa que seu ambiente a ser testado pode continuamente receber novas entradas de carga, independente como irá ser tratado isso.

Fechado significa que seu ambiente apenas pode receber nova carga a partir de um determinado momento ou critério pré-estabelecido.

• Entrada de carga em concorrência, sequencial e/ou paralela.

Quais são as vantagens dos Testes de Performance?

Agora, vamos falar sobre as principais vantagens dos Testes de Performance:

1. Assegurar disponibilidade, saúde e estabilidade do ambiente;
2. Localizar pontos em que seu ambiente apresenta “gargalos”;
3. Conhecer pontos de vulnerabilidade de segurança no seu ambiente;
4. Produzir métricas para diferentes propósitos como:

•  Ter um baixo tempo médio de recuperação do ambiente;
•  Ter uma documentação sobre a performance do seu ambiente;
•  Montar estratégias de recuperação (melhor se forem automatizadas);
•  Criar estratégias de teste.

Testes de Performance na prática

Agora, iremos colocar a mão na massa para criar um step-by-step de como então desenhar sua estratégia!

1. Primeiro e mais importante ponto: porque e para que você vai criar seus testes? Precisamos ter muito claro o porquê vamos testar esse ambiente. Por exemplo, você vai criar esses testes porque estamos enfrentando ataques brute force no ambiente e precisamos testar isso também ou porque teremos uma black friday se aproximando?
2. Depois, em literal consequência ao anterior, qual é o seu objetivo final? Alguma área requisitou para um propósito? Benchmark? Testar os pontos de maior conversa ou de maior criticidade dentro de um microsserviço? Para entender melhor o seu ambiente e assim criar uma documentação?

2. Identificar qual ou quais ambientes serão o alvo.

3. Consequentemente, levantar todos possíveis gargalos que esse ambiente já tenha, levantar possíveis filtros que já exista. Por exemplo, firewall ou algumas regras de bloqueios de região, IP, etc.

4. Levantar uma documentação prévia sobre esse ambiente e possíveis métricas já existentes.
5. Definir ONDE será executado o teste (máquina local, docker, cloud, etc). Lembre-se que cada ambiente possui suas limitações.

6. Começar de fato agora com todas essas informações a criar seu plano de teste. Assim, defina quais métricas serão usadas e avaliadas: Na criação: definição de tipos de injeção, qual a carga a ser enviada e quais os cenários. No resultado: fazer asserções (se necessárias), coleta das métrica, geração de reports e persistência em banco de dados.

Exemplos básicos de métricas:

• Tempo de resposta, médio X pico;
• Latência;
• Taxa de erros;
• Uso de CPU e Memória;
• Tempo médio de recuperação;

Esses exemplos se aplicam em diversos contextos como HTTP, Infraestruturas, Brokers, Filas, banco de dados, etc.

7. Terminado seu plano e sua execução, agora é só montar toda documentação e reports e entregar os resultados!  

Conclusão

Neste artigo, pudemos ver uma pequena parte, a ponta do iceberg, de o que é e como funcionam os testes de performance e sua enorme importância em diversos contextos. Então, não deixem de pesquisar mais a fundo e procurar oportunidades de inserir no seu contexto.

Por fim, seguem alguns links interessantes e ferramentas que recomendo:

• https://gatling.io/
• https://locust.io/
• https://stackify.com/ultimate-guide-performance-testing-and-software-testing/
• https://www.pagerduty.com/resources/learn/what-is-chaos-testing/

Autor: Francisco Antônio Navarro Moral.

[adrotate banner=”5″]

Veja também:

Como fazer testes automatizados com react

Artigos sobre Testes da Luby

O post Testes de Performance: o que são e como configurar? apareceu primeiro em Luby Software.

[adrotate banner=”4″]

O que são testes de software?

Um teste de software é um método cuja finalidade é avaliar e verificar se o sistema faz o que foi predisposto. Ou seja, se corresponde aos requisitos esperados, visando garantir um produto que seja o mais livre possível de falhas.

Benefícios dos testes

A prática de testar aplicações traz inúmeros benefícios no que tange o desenvolvimento de software, entre elas podemos citar:

• Controle de qualidade: um requisito essencial para uma aplicação é a qualidade dos serviços que ela presta, os testes permitem um melhor controle da qualidade do software;
• Controle de segurança: testar as aplicações também pode ajudar a identificar falhas de segurança e corrigir vulnerabilidades;
• Identificar funcionalidades inválidas ou incorretas: bugs podem ser caros e até perigosos, a ausência de uma vírgula ou a falha no processamento de uma transação, por exemplo, podem causar perdas de negócio;
• Satisfação do cliente: quanto mais um produto atende às necessidades do cliente maior é o grau de satisfação.

Principais tipos de testes

Os testes surgem com objetivos e estratégias específicas e existem diversos tipos diferentes, alguns deles são:

• Unitários: testam se o componente da aplicação funciona como esperado.
• De integração: verificam se componentes do software funcionam em conjunto.
• E2E (end-to-end): também conhecido como teste de ponta a ponta, sua função é simular a interação de um usuário real.

Como os testes funcionam?

O teste de software geralmente é formado de etapas comuns, como a definição do ambiente de teste, o desenvolvimento dos casos, a escrita dos scripts e a análise dos resultados. Assim, uma boa abordagem de testes envolve a interface de programação de aplicações (API) e a interface de usuário.

Pode ser realizado de forma manual ou automatizada, sendo, os testes automatizados mais rápidos e eficientes para testar as funcionalidades de sistemas maiores. Além disso, podem servir também como forma de documentação para que novos integrantes no projeto consigam compreender melhor todo o cenário de funcionamento da aplicação.

Como funcionam os testes no React Native?

Os testes em aplicações para dispositivos móveis funcionam de maneira semelhante aos testes para aplicações web. Então, podem ser testados os componentes, as funcionalidades e até mesmo todo o funcionamento do aplicativo.

Quais são as ferramentas disponíveis?

• Jest: é um interpretador de teste JavaScript para testar componentes individuais. Ele oferece velocidade de interação com recursos, como módulos de mocking e temporizadores;
• React Testing Library: permite testar componentes por meio de um conjunto de helpers;
• Detox: realiza testes de ponta a ponta em aplicativos que estejam sendo executados em dispositivos reais ou emuladores;
• Cypress: framework para testes de ponta a ponta é uma opção para testar de forma web aplicações mobile criadas com Expo CLI;
• Appium: utiliza um web driver para testar aplicações nativas ou web para dispositivos móveis e também sistemas híbridos no Android ou iOS.

Criando testes automatizados utilizando Cypress

1ª etapa

Para instalar o Cypress, basta navegar até o diretório do projeto que será testado e utilizar:

Em seguida, rodando o comando abaixo, um diretório chamado cyrpess e um arquivo cypress.json serão adicionados.

Uma janela também será aberta onde irão aparecer todos os arquivos de testes. Assim, ela possibilita criar novos arquivos de testes. Atualmente, o cypress possui Edge, Chrome e Electron como opções de navegadores, também é possível consultar a documentação e até realizar configurações.

2ª etapa

No arquivo cypress.json, devemos configurar a url como o local onde o Expo CLI irá executar o aplicativo, como mostra a imagem a seguir.

Embora os testes sejam executados em um ambiente web, é possível simular as dimensões reais de dispositivos móveis adicionando viewportWidth e viewportHeight, essas propriedades são opcionais.

3ª etapa

Os testes devem ser colocados na pasta integration e devem ter o formato [nomeDoArquivo].spec.js. Além disso, o cypress possui guias de configuração e migração que podem ser consultados em sua documentação.

4ª etapa

Para testar o aplicativo, foi criado um arquivo com testes simples para verificar algumas funcionalidades. Assim, os testes seguem uma sequência padrão em que:

• describe descreve o conjunto de testes criado;
• beforeEach é executado antes dos testes;
• it é um bloco de teste no formato it(‘descrição do teste’, função);
• os métodos de testes são no formato cy.[método];
• cy.visit() navega até uma rota específica da aplicação;
• o método cy.get() busca um elemento na tela;
• click e type simulam eventos de click e digitação;
• em type é preciso passar uma string com o texto a ser digitado;
• should cria uma afirmação que deve ser verificada;
• no caso dos testes acima should(‘be.visible’) está definindo que o elemento deve está visível na tela.

Os testes podem ser executados clicando no Botão Run (todos os testes serão executados). Bem como também é possível clicar em um arquivo específico de teste, o aplicativo precisa estar sendo executado pelo Expo de forma web. Após a execução, teremos o seguinte resultado:

Criando testes automatizados utilizando Appium

1ª etapa

Para este exemplo de teste, iremos utilizar o apk de demonstração disponibilizado pela appium e começar a configurar o setup de testes. Para instalar o Appium, basta rodar no terminal o comando abaixo:

Instalando o appium-doctor, o comando no terminal irá mostrar se existe alguma dependência ou variável de ambiente que sejam necessárias e não estejam instaladas ou configuradas corretamente.

Em seguida, será preciso atualizar o package.json para a configuração utilizando o webdriverio, adicionando um comando de test, timeout para o mocha e as bibliotecas assert, chai, mocha e webdriverio como dependências de desenvolvimento, depois usar npm install para a instalação. A ferramenta também disponibiliza exemplos de testes para linguagens de programação diferentes.

2ª etapa

Na sequência, vamos criar um diretório chamado helpers e adicionar dois scripts, o primeiro apps.js irá definir os aplicativos que serão utilizados. No exemplo, só será retornado o caminho para o arquivo apk, mas é possível configurá-lo para retornar caminhos para aplicativos diferentes, de acordo com condicionais.

O próximo helper caps.js retorna as opções de configuração, como o nome da plataforma, tipo de automação, nome do dispositivo android, a versão que será utilizada e o aplicativo que será definido nos testes. Além disso, ele ajusta os parâmetros de conexão com o servidor do Appium.

3ª etapa

No arquivo de testes, que deve ter o formato [nomeDoArquivo].test.js, importamos o webdriverio, o assert da biblioteca chai e as opções de android dos helpers criados anteriormente.

Além disso, definimos o caminho do aplicativo em androidOptions.capabilities.app = app, o formato de definição dos testes é describe(‘descrição do conjunto de testes’, função). E, para os testes, it(‘descrição do teste’, função), before() conecta as configurações do android que definimos no helper caps.js com o webdriverio antes dos testes começarem.

O formato de busca aos elementos é feito como client.$(‘~Parâmetro de Seleção’), onde cliente é a conexão feita com o webdriverio.

Dessa forma, podemos ainda simular eventos de touch com o método [element].click() e digitação com [element].setValue(). Também é possível simular o click no botão de retorno do dispositivo móvel usando client.back(). O método [element].getText() retorna o conteúdo de texto do elemento que pode ser comparado com o comando assert.equal().

A função assert da biblioteca chai possui métodos de comparação como isObject() e isNull() para verificar se o elemento comparado é um objeto ou nulo. Também é possível fechar a conexão com o webdriverio utilizando client.deleteSession().

4ª etapa

Para a execução dos testes, é preciso iniciar o appium rodando no terminal appium e npm test, para que o mocha inicie a execução dos scripts de teste. Após a execução, teremos o seguinte resultado:

O código fonte para os testes apresentados se encontra neste repositório.

Considerações finais

Testes automatizados trazem diversos benefícios para um ambiente de desenvolvimento. Dessa forma, são ótimos recursos para facilitar a verificação das funcionalidades e possíveis falhas de uma aplicação.

No React Native, ferramentas como Cypress e Appium proporcionam ambientes de testes automatizados que podem ser configurados de acordo com necessidades e preferências específicas.

Autora: Crislâine dos Santos Costa.

[adrotate banner=”5″]

Veja também:

Testes automatizados com adonis JS

Testes de performance

O post Testes Automatizados no React Native apareceu primeiro em Luby Software.

[adrotate banner=”4″]

Já ouviu falar de um site chamado Human Benchmark? É uma página muito interessante com diversos testes em forma de jogos para mensurar e ranquear suas capacidades cognitivas como tempo de reação, capacidade motora, memória visual, memória verbal, entre várias outras. Assim, você pode criar uma conta para salvar as pontuações nestes testes, de forma que os usuários possam acompanhar a própria evolução e comparar seus resultados com o mundo inteiro! 

Entre os testes mencionados, há um que eu particularmente considero muito interessante: o teste de memória verbal. Ele te apresenta uma palavra aleatória e, logo abaixo da palavra exibida, você tem dois botões: “new” e“seen”. A lógica é bem simples, se a palavra mostrada for nova, você clica no botão “new”, caso a palavra já tenha sido mostrada anteriormente, você clica no botão “seen”, fácil né?

Bem, no começo, realmente é. Entretanto, conforme a lista de palavras aumenta, fica cada vez mais difícil saber se a palavra atual já foi mostrada ou não, e você só pode errar três vezes, se não é game over!

Como criar um bot para teste automatizado com NodeJS e Puppeteer

Se pararmos para pensar, os passos para pontuar neste teste são bastantes simples, correto? Basta ver a palavra, verificar se ela já foi mostrada ou não e, com base na conclusão do passo anterior, apertar o botão correto. Podemos observar que temos uma rotina muito bem definida.

Como todo programador, ao me deparar com essa rotina enquanto realizava esse teste, tive aquele momento de reflexão: “Hmmmm, eu poderia escrever um código para executar essa rotina de forma muito mais eficiente”.

E, para fazer isso, além do nosso bom e velho Node.js, vamos utilizar uma lib chamada Puppeteer. Para quem não conhece, ela é uma biblioteca mantida pela mesma equipe do Chrome Devtools. Com ela, podemos criar um bot para testes e realizar a automação de tarefas no browser, entendeu? Então, bora codar!

Colocando a mão (na massa) no teclado

Antes de tudo, vamos criar uma pasta para o nosso projeto. Utilizando o comando abaixo no linux, podemos criar e definir nosso diretório atual para o recém-criado benchmark-bot.

Agora, dentro da pasta que criamos, vamos instalar as nossas dependências. Neste caso, só precisaremos instalar uma única library: o Puppeteer.

(Na data deste artigo, a versão atual do Puppeteer é a 9.1.1)

Não se esqueça de adicionar a seguinte linha no seu package.json. Assim, podemos usar features poderosas das novas versões do Javascript (como EcmaScript Modules) e o charmoso Top Level Await, que será muito útil (graças à natureza assíncrona do Puppeteer). 

Hora de codar!

Com tudo devidamente acertado, podemos começar com a parte divertida de criar um bot para testes!

O Puppeteer fornece duas formas de acessar uma instância do browser. Dessa forma, podemos nos conectar a uma instância do Chrome já aberta ou deixar ele próprio iniciar uma instância. No nosso index.js, vamos começar a escrever nosso código.

Executando o código acima, podemos ver o Puppeteer executando nosso browser:

Ótimo! Mas um navegador aberto com uma página em branco não é muito interessante, certo? Então, vamos implementar a parte que irá fazer a navegação até a página que queremos, você vai ver como é simples!

Com apenas uma chamada de método, podemos navegar até a página necessária. Agora, executando o código que escrevemos até aqui, podemos ver o navegador exibindo nossa página.

Nesse momento, precisamos que o nosso bot clique no botão “Start” para que o jogo seja iniciado, certo? Com o Puppeteer, isso é moleza! Acompanhe o código a seguir e veja que podemos fazer isso com duas linhas de código.

Rodando o nosso código, vemos que (como o esperado) nosso bot aperta o botão “Start” e o teste é iniciado. Após o teste ser iniciado, temos três elementos com os quais o nosso bot irá interagir: a palavra atual que está sendo mostrada (e os dois botões abaixo dela); o botão “Seen” será clicado quando a palavra atual já tiver sido mostrada antes; e o botão “New” quando for uma palavra nova. 

Testando nossa memória

Esse jogo busca testar sua memória de curto prazo. Ou seja, ele vai testar quantas palavras você consegue se lembrar em um pequeno espaço de tempo.

Enquanto humanos, nosso cérebro não é “lá essas coisas” quando o assunto é guardar muitos valores em pouco tempo. Afinal, quem nunca fez aquele esforço para decorar um número de telefone quando não tinha nenhum papel e caneta por perto? Enquanto programadores, temos a nossa disposição uma engenhoca extremamente eficiente para armazenar e manipular quantidades monumentais de valores, sem esquecer de um único zero sequer: o computador.

Para termos acesso à essa máquina com superpoderes, nossas principais ferramentas são as linguagens de programação. Felizmente, a grande maioria dessas linguagens nos fornecem maneiras fáceis para armazenar dados.

Como já falamos, para resolver esse jogo, o nosso robô precisa saber qual é a palavra atual, ter uma lista com todas as palavras que já apareceram e também ter acesso aos dois botões para interagir com o teste. Então, faz sentido guardarmos a palavra atual em um variável e um array parece ser perfeito para armazenar as palavras que foram mostradas. Dessa forma, também já sabemos como acessar os botões que precisamos, certo? Vamos ao código!

Algoritmo

Agora que temos nossa estrutura montada, vamos criar as funções que vão possibilitar ao nosso robô entender o jogo e tomar as decisões corretas. O algoritmo é bem simples!

O nosso robô vai ler a palavra que está sendo mostrada no momento e conferir se essa palavra foi salva no nosso array. Caso tenha sido, isso significa que a palavra já foi mostrada anteriormente. Então, o robô deve clicar no botão “Seen”. Caso contrário, significa que a palavra é nova. Assim, o nosso robô irá armazenar essa palavra dentro do array e clicar no botão “New”. Depois disso, esperamos um delay de 50 milissegundos para garantir que a palavra foi atualizada e então podemos repetir tudo novamente, Ad infinitum!

Conclusão

Em poucos minutos, com o bot para testes, atingimos uma pontuação de mais de 6000 pontos!

Puppeteer é uma biblioteca extremamente poderosa para se ter no cinto de ferramentas, abstraindo todo o trabalho pesado para você. Ele é muito útil não só para automatizar ações na web como acabamos de fazer, mas também para escrever testes de integração (principalmente quando rodamos no headless mode).

Achou divertido criar um bot para testes? No site do Human Benchmark, existem vários outros testes esperando para serem automatizados, que tal programar um robô para algum dos outros testes e experimentar a magia do Puppeteer? Se você testar ou tiver alguma dúvida, deixe o seu comentário aqui na publicação!

Você pode acessar o repositório através deste link.

[adrotate banner=”5″]

Veja também:

Como executar testes de performance.

Poised Testing: o que é e como utilizar!

Biblioteca de Artigos Sobre Desenvolvimento de Software

O post Como criar um bot para testes capaz de superar o cérebro humano apareceu primeiro em Luby Software.