Documentação dos Testes do Sistema SLAVE ONE

Testes Front-End Slave One

Documentação dos Testes do Sistema SLAVE ONE

Esta documentação descreve os testes realizados no sistema SLAVE ONE pelos programadores front-end Gustavo e Marcela, do LEDS. Nos testes, foram utilizados

• software Cypress juntamente com a ferramenta Cucumber, que suporta o desenvolvimento orientado por comportamento (BDD).

O que é o Cypress?

O Cypress é uma ferramenta para testes de regressão automatizados de aplicações web. Ele oferece alta precisão nos testes, permitindo a criação de diversos cenários que facilitam o trabalho dos testadores e desenvolvedores da equipe, proporcionando testes rápidos e eficazes.

O que é o Cucumber?

O Cucumber é uma ferramenta que suporta BDD, oferecendo várias vantagens, como a utilização de uma linguagem natural (em Português, Inglês, entre outras). Isso permite um entendimento mais claro dos testes entre as equipes. Utilizamos o padrão do Cucumber para realizar os testes.

O que é o BDD?

Behavior Driven Development (BDD) é um conjunto de práticas de engenharia de software que integra regras de negócios com linguagem de programação, focando no comportamento do software. Ele criou um padrão nos testes, permitindo uma comunicação eficaz entre todos os envolvidos no projeto.

Instalação do Cypress, Cucumber, XPath e .env

1- Instalação do Cypress: Inicialmente, foi necessário instalar o Cypress. Utilizamos o comando direto no terminal do nosso projeto no VSCode:

npm install cypress

Esse comando cria uma pasta do Cypress dentro do projeto, contendo arquivos importantes para os testes.

2- Instalação do Cucumber: Em seguida, instalamos o Cucumber no projeto:

npm install --save-dev cypress cypress-cucumber-preprocessor

3- Instalação do XPath: Devido ao uso do Quasar, enfrentamos dificuldades com alguns componentes, sendo necessário utilizar o XPath para identificar os campos do sistema. O comando utilizado foi:

npm install -D cypress-xpath

4- Instalação do .env: Por fim, instalamos o .env para refatorar a parte de login do nosso código, melhorando sua organização visual. Embora opcional, sua instalação foi realizada com o comando:

npm install dotenv --dev

Tipos de Testes

O Cypress permite dois tipos de testes: e2e e testes de componentes.

1- Teste e2e (end-to-end): Utilizado pela nossa equipe, esse tipo de teste verifica toda a experiência do aplicativo, de ponta a ponta, garantindo que cada fluxo funcione conforme o esperado.
2- Teste de componentes: Permite testar os componentes do sistema de design de forma isolada, garantindo que cada um corresponda às expectativas.

Após instalar o Cypress, utilizamos o comando no terminal: npx cypress open

Esse comando executa o Cypress e abre uma interface visual intuitiva, permitindo a escolha do tipo de teste a ser realizado (e2e ou component testing) e do navegador preferido para a execução dos testes.

Estrutura dos Testes

Ao escolher o tipo de teste, uma pasta e2e é criada. Para melhorar a organização, criamos também uma pasta step_definitions. Nessa pasta, existem arquivos .feature e, no caso do SLAVE ONE, arquivos .ts (TypeScript, linguagem utilizada no frontend que suporta também o Cucumber).

• Arquivos .feature: Esses arquivos são escritos seguindo o padrão do Cucumber, em uma linguagem mais acessível (escrevemos em inglês) e são reconhecidos no Cypress como "SPECS".
• Arquivos .ts: Esses arquivos traduzem os cenários dos testes para uma linguagem de programação que a máquina entende, especificando o que será feito nos testes.

Arquivos Feature

Utilizando o padrão do Cucumber, criamos testes para cada tela com cenários positivos e negativos. No sistema SLAVE ONE, por exemplo, há uma tela de CRUD de “Categoria” que cria, edita, deleta e lista as categorias existentes no sistema. Utilizaremos essa tela como referência para demonstrar como os testes foram realizados.

O primeiro cenário reproduzido é positivo, no qual uma categoria é criada e tudo ocorre como esperado, com a API retornando o status 200 - Requisição bem-sucedida.

Cenário positivo

Detalhamento dos Cenários de Teste

Feature: Cadastro de Categorias

A feature em questão trata do cadastro de categorias no sistema. O objetivo é garantir que o processo de criação de uma nova categoria funcione corretamente, tanto para cenários de sucesso quanto para casos de erro.

Background: Cenário Inicial

O background define o cenário inicial necessário para os testes. Neste caso, envolve a preparação do ambiente e a realização do login no sistema.

• Given e And: Esses conectivos do Cucumber significam "Dado" e "E", respectivamente. Eles são utilizados para descrever as condições iniciais dos testes automatizados. No contexto atual, eles garantem que os testes realizem o login antes de iniciar o cenário de cadastro de uma categoria. Por exemplo:

Given que visitei a tela de login And fiz o login com sucesso

Scenario Outline: Descrição do Cenário de Teste

O scenario outline descreve o cenário específico que será testado. No caso do cadastro de categorias, o cenário envolve a navegação para a página de criação de uma nova categoria e a realização das ações necessárias para completá-lo.

• When: Este conectivo do Cucumber, "Quando", indica uma ação a ser realizada. Por exemplo:

_ When eu vou para a página de criar uma nova categoria. Isso redireciona o usuário para a página de criação._

• And: Novamente, o conectivo "E" é utilizado para encadear ações essenciais. Por exemplo:

And eu digito no campo '' de categoria And eu clico no botão de criar

• Then: O "Then" serve para indicar o resultado esperado. Por exemplo: Then eu tenho a mensagem da nova categoria criada
• Examples: Os exemplos especificam os dados que serão utilizados nos testes. Podem ser quantos forem necessários. Exemplo de tabela:

| name | start date | final date |

| categoria | 16/12/2002 | 20/12/2024 |

Cenários de Erro

Os cenários seguintes tratam dos casos de erro, assegurando que o sistema responda corretamente a entradas inválidas.

1. Tentativa de Criação de Categoria Vazia:
   1. Quando o usuário tenta criar uma categoria sem preencher os campos obrigatórios, a API deve retornar um erro.
2. Verificação de Mínimo de Caracteres:

○ O backend do SLAVE ONE verifica se os campos possuem no mínimo 3 caracteres. Se a entrada não cumprir essa regra, o sistema deve alertar o usuário sobre o erro e impedir o cadastro.

Cenário de erro com mínimo de caracteres

Este cenário trata da criação de uma categoria com um nome inválido, verificando se o sistema retorna a mensagem de erro apropriada.

• When e And: Esses conectivos redirecionam para a página de criação de categoria e executam as ações necessárias. Por exemplo:

_ When eu vou para a página de criar uma nova categoria And eu digito no campo 'name' de categoria _

And eu clico no botão de criar

• Then: Diferente do cenário de sucesso, aqui o "Then" verifica se a mensagem de erro apropriada é exibida. Por exemplo:

_ Then eu vejo a mensagem de erro ''_

• Examples: Nos exemplos, utilizamos uma nova coluna para a mensagem de erro, especificando os dados de teste que devem causar o erro. Todos os nomes de categoria têm menos de 3 caracteres. Exemplo de tabela:

Copiar código

| name | message | | ab | Nome da categoria muito curto | | xy | Nome da categoria muito curto |

Cenário de erro com campo nulo

Este cenário trata da criação de uma categoria com um nome nulo, verificando se o sistema retorna a mensagem de erro apropriada.

• When e And: Redireciona a página de criação de categoria. Colocamos o caso de erro nesse conectivo “And” que serve para deixar o campo de nome da categoria em branco
• Then: O cenário esperado não é criar uma categoria com sucesso, e sim exibir uma mensagem de erro, instanciando ela como string ‘’

Note que nos exemplos, não possuímos a coluna de “name” pois ela deverá ficar vazia para que nosso teste de erro retorne a resposta esperada

Arquivos .ts

Para garantir o funcionamento adequado dos nossos testes, é necessário traduzir essas features em código que a máquina consiga interpretar. A seguir, apresentamos o processo de criação do arquivo TypeScript utilizado para compreender os testes especificados na nossa feature.

Primeiramente, foi criado um arquivo denominado "pageObjects", que tem como principal finalidade auxiliar na refatoração do nosso código de testes. Neste arquivo, foram inseridos diversos elementos da página de categoria que serão utilizados, além de várias funções que são chamadas dentro do código.

Declaramos todos os elementos necessários para que o teste possa concluir o cenário com sucesso. No objeto "elements", especificamos o caminho para a toolbar, que é onde, no sistema, acessamos as páginas. Neste caso, queremos acessar a página de categoria, então também instanciamos o botão de "categoria", que possui a rota para essa página.

Em seguida, no mesmo arquivo, criamos uma classe denominada "CreateCategory", que chama variáveis estáticas responsáveis pela criação da categoria. Por exemplo, temos a variável estática "goToCreateCategoryPage", que, como o próprio nome sugere, redireciona o teste para a página de criação de categoria. Dentro dessa classe, manipulamos os elementos previamente instanciados para acessar a página.

Mas onde iremos, de fato, integrar nosso roteiro com o TypeScript?

O próximo passo é criar um arquivo dentro da pasta "e2e", na subpasta "step_definitions". Esse arquivo seguirá o roteiro que criamos e utilizará as funções definidas no arquivo "pageObjects" anteriormente explicado.

Utilizando o Cucumber com seus conectivos, voltamos ao arquivo .feature e utilizamos exatamente as frases escritas nele. Em seguida, chamamos a função criada no arquivo .ts para executar a ação correspondente ao cenário. Abaixo, mostramos como foi implementado na nossa criação de categoria:

Executando os Testes

Para executar os testes, abra o terminal no diretório do seu código e insira o comando npx cypress open. Esse comando abrirá o Cypress previamente configurado, que automaticamente reconhecerá e exibirá as especificações de teste (specs).

Iniciar testes específicos é um processo simples: basta selecionar a spec desejada, e o Cypress executará o código correspondente. Caso ocorra algum erro durante a execução, o Cypress exibirá uma indicação no canto esquerdo da tela, juntamente com a descrição detalhada do erro.

Refatoração do código

Para que nosso código fique mais limpo e não haja muita repetição de código, foi realizado uma refatoração utilizando o método fábrica na tela de login para evitar que os campos sejam chamados várias vezes, pois sempre que realizamos um cenário no nosso sistema, é necessário que o software acesse a url do nosso sistema e realize login com ele.

Dessa forma, o método fábrica cria um object que passa o “emailInput” que contém

• email que o usuário utilizará para fazer o login, e o campo “passwordInput” que possui a senha do sistema.