- 1 Apresentação
- 2 Pré-requisitos
- 3 Dependências
- 4 Scripts
- 5 Estrutura do projeto
- 6 Por onde seguir
- 7 Grupo
Seja bem-vindo ao projeto de automação de testes em Cypress, utilizando BDD (Behavior-Driven Development), Gherkin e Page Objects. Este sistema foi desenvolvido com o objetivo de aprimorar a eficiência e confiabilidade dos testes automatizados em grupo, seguindo as melhores práticas da indústria.
O projeto concentra-se na construção de uma estrutura robusta de automação de testes em Cypress, adotando práticas de Desenvolvimento Orientado a Comportamento (BDD) e utilizando Gherkin para especificações. O escopo do teste abrange uma página governamental específica: o portal Meu INSS.
baseURL: https://meu.inss.gov.br/
O Projeto tem como principais objetivos:
- Implementar testes automatizados que garantam a integridade e funcionamento correto da página Meu INSS.
- Utilizar práticas de BDD e Gherkin para uma especificação clara e compreensível dos testes.
- Empregar o padrão Page Objects para facilitar a manutenção e escalabilidade dos testes.
- Promover a colaboração eficiente entre membros da equipe na execução e desenvolvimento de testes automatizados.
- Apresentação:
Clique para Assistir 👇
https://www.youtube.com/watch?v=ht44TG5Z34I
- Node.js (preferencialmente LTS mais recente);
- NPM (instalado com Node.js);
- Dependências do projeto;
- Acesso à aplicação rodando;
- Mocks habilitados;
| Nome | Função | Documentação |
|---|---|---|
| Cypress | Biblioteca de testes automatizados multicamada | Link aqui |
| cypress cucumber preprocessor | Aplicação de Cucumber para Cypress permitindo utilização de arquivos .feature contendo as instruções do teste em Gherkin | Link aqui |
| multiple cucumber html reporter | Gera reports em HTML contendo dados da execução dos testes e seus resultados | Link aqui |
npm run {scriptName}
| Nome | Utilização |
|---|---|
| cy:open | Abre o runner do Cypress com painel que permite analizar passo-a-passo a execussão dos testes e acessar os dados trafegados via browser e funcionalidade de time lapse dinâmico; |
| cy:run | Executa os testes em modo headless. |
| report:gen | Gera o relatório dos testes executados. |
| Nome | Função |
|---|---|
| cypress | o que diz respeito ao projeto de testes deve estar localizado dentro da pasta cypress. |
| support | contém os arquivos de comandos personalizados cypress. |
| e2e | os testes devem estar situados dentro desta pasta. Na raíz dela uma subpasta features contendo arquivos .feature com os cenários de teste em Gherkin. Em uma subpasta steps teremos os arquivos step.js com a implementação dos steps de testes. |
| fixtures | esta pasta contém as massas de dados fixas. |
| pages | seguindo o padrão de projeto PageObjects, nesta pasta constam os arquivos page.js que serão classes com métodos de ação específicos de cada página além dos seletores de elementos usados ao longo dos testes (e métodos getters retornando estes elementos em forma de return cy.get(seletor), permitindo encadear ações e validações quando invocados). |
| Sufixo | Função |
|---|---|
| .feature | contém os cenários de teste escritos em Gherkin. O sistema deste framework usa este arquivo para organizar os steps, ordem e repetições que devem ser executadas podendo também conter aqui dados a serem passados para o código em forma de parâmetros, variáveis, tabelas e objetos. Ao executar o teste o sistema acessará estes arquivos e buscará a implementação de cada step listado executando em ordem. Essa busca será realizada nos arquivos dentro da pasta e2e > steps. Caso não encontre, seguira a busca em direção à pasta e arquivo spec nomeados de acordo com o arquivo .feature correspondente. |
| .spec.js | implementação de cada step definido em arquivo .feature.Em casos de erro do tipo missing step implementation o sistema possivelmente não encontrou uma implementação com o exato texto do step nas pastas adequadas durante a busca. |
| cypress.config.js | este é o arquivo de configuração geral do projeto Cypress. Aqui apontamos a base URL alvo do teste, comportamentos do runner, uso de plugins como Cucumber e possíveis variáveis de ambiente entre outras opções. |
- Defina e siga desde o início um padrão de escrita Gherkin (primeira ou terceira pessoa, verbos no infinitivo ou conjugados, granularidade das instruções);
- Procure manter as instruções (steps) concisas e independentes;
- Faça uso de instruções e commands para preparação de cenários de teste (pré-requisitos) de maneira mais otimizada e legível;
- TESTES TAMBÉM GOSTAM DE CLEAN CODE!
- Se o projeto está confuso demais, pode melhorar;
- Se ainda está confuso, você pode melhorar;
- Bons colegas nos ajudam a melhorar, mas isso depende do nosso esforço e disposição;
- O TESTE É DO TIME!
- Mantenha a organização das pastas;
- Gostamos de mocks nos testes;
- Testes independentes são legais.
- Testes são feitos pra serem executados;
- Testes automatizados devem ser o mais automatizados possível;
- Testes instáveis (flaky) devem ser aprimorados;
- Se não der pra escrever testes para a aplicação, talvez ela tenha baixa testabilidade;
- Aplicações de baixa testabilidade devem melhorar;
- Um bom dev testa;
- Um bom QA planeja e testa;
- Carlos Augusto Alves Bezerra de Santana
- Ewerton Alexander de Oliveira Batista
- Hugo Oliveira Facundo de Almeida
- Luan Antony Rocha de Aguiar
- Vinícius dos Reis Loch
- Wagner de Sousa Patrício Junior
 Ewerton Alexander 👨🚀 |
 Hugo Facundo 👨🚀 |
 Luan Antony 👨🚀 |
 Carlos Augusto 👨🚀 |
 Vinícius Loch 👨🚀 |
 Wagner Patricio 👨🚀 |