Test Automation · Cypress · Cucumber

Automação de Testes com Cypress + Cucumber BDD Test Automation with Cypress + Cucumber BDD

Testes end-to-end do site Adopet — cobrindo os fluxos de cadastro, login, e contato com adotante, aplicando boas práticas de BDD (Behavior Driven Development) para descrever comportamentos e cenários de teste de forma clara para times de negócio e técnicos.

End-to-end testing of the Adopet website — covering registration, login, and contact flows, applying BDD (Behavior Driven Development) best practices to describe behaviors and test scenarios clearly for both business and technical teams.

Cypress Cucumber Gherkin JavaScript BDD E2E Testing


Processo de trabalho Work process

Fase 01Phase 01
🔍
Teste exploratórioExploratory testing
Navegação livre para entender o sistema e identificar os comportamentos existentes Free navigation to understand the system and identify existing behaviors
Fase 02Phase 02
📋
Teste funcionalFunctional testing
Validação estruturada dos fluxos e mapeamento dos cenários a serem automatizados Structured validation of flows and mapping of scenarios to be automated
Fase 03Phase 03
⚙️
Automação BDDBDD Automation
Escrita dos cenários em Gherkin e implementação das step definitions em Cypress Writing scenarios in Gherkin and implementing step definitions in Cypress

Stack utilizada Tech stack

💻

Cypress

Framework de testes E2E com execução em browser real e feedback instantâneo

E2E testing framework with real browser execution and instant feedback

✳️

Cucumber

Integração via @badeball/cypress-cucumber-preprocessor para executar features Gherkin

Integration via @badeball/cypress-cucumber-preprocessor to execute Gherkin features

📝

Gherkin

Linguagem natural para descrever cenários com Given / When / Then

Natural language to describe scenarios with Given / When / Then


Decisões técnicas e desafios Technical decisions and challenges

Testes estáveis sem cy.wait Stable tests without cy.wait

Usei .should('be.visible') combinado com timeout nos asserts de mensagens de erro, evitando esperas fixas e tornando os testes mais resilientes a variações de latência.

Used .should('be.visible') combined with timeout in error message asserts, avoiding fixed waits and making tests more resilient to latency variations.

Seletores robustos com data-test Robust selectors with data-test

Priorizei atributos data-test em vez de classes CSS ou textos visíveis, garantindo que mudanças de layout não quebrem os testes desnecessariamente.

Prioritized data-test attributes instead of CSS classes or visible text, ensuring that layout changes do not break tests unnecessarily.

Fragilidade na tela de contato Fragility in the contact screen

A página de contato não segue o padrão data-test do restante do sistema. Os seletores usam IDs genéricos (#name, #phone), o que torna essa parte mais suscetível a quebras — identificado e documentado como ponto de melhoria.

The contact page does not follow the data-test standard of the rest of the system. Selectors use generic IDs (#name, #phone), making this part more susceptible to breakage — identified and documented as an improvement point.


O que aprendi e apliquei What I learned and applied

01

Testes exploratórios como base Exploratory testing as a base

Entender o sistema de forma livre antes de automatizar garante cenários mais realistas e completos.

Understanding the system freely before automating ensures more realistic and complete scenarios.

02

Linguagem Gherkin Gherkin language

Descrever cenários com Given, When e Then aproxima a especificação do negócio da automação.

Describing scenarios with Given, When, and Then brings business specification closer to automation.

03

Step definitions reutilizáveis Reusable step definitions

Conectar os passos Gherkin ao JavaScript com parâmetros dinâmicos, mantendo organização e reuso.

Connecting Gherkin steps to JavaScript with dynamic parameters, maintaining organization and reuse.

04

Estabilidade de testes Test stability

Identificar e corrigir testes flaky, substituindo esperas fixas por asserts condicionais e timeouts.

Identifying and fixing flaky tests, replacing fixed waits with conditional asserts and timeouts.

05

Análise crítica do sistema Critical system analysis

Reconhecer inconsistências no front-end, como a ausência de data-test, e documentá-las como riscos de manutenção.

Recognizing inconsistencies in the front-end, such as the absence of data-test, and documenting them as maintenance risks.


Repositório no GitHub: GitHub Repository:

Você pode ver o projeto clicando aqui You can see the project by clicking here