Como fazer login com Cypress em diferentes ambientes

Protegendo dados sensíveis, tais como usuário e senha

Recentemente, criei um vídeo na playlist cy.handsOn no Canal TAT, sobre como rodar testes contra diferentes ambientes com Cypress usando arquivos de configuração.

Neste vídeo, abordei a possibilidade de alterar a baseUrl para apontar para diferentes ambientes por meio de arquivos de configuração específicos.

Mas o que fazer com os dados sensíveis, tais como as credenciais para autenticação em uma mesma aplicação, implantada em diferentes ambientes?

É exatamente isso que vou te ensinar neste conteúdo!

Imaginemos uma aplicação implantada em três ambientes diferentes, cada um com suas credenciais específicas.

Os ambientes são:

• Local (seu computador)
• Homologação
• Produção

Para fazer login na aplicação (em qualquer um dos ambientes), é necessário o e-mail e senha do usuário.

Imaginemos também que, no arquivo de configurações do Cypress (cypress.json, ou cypress.config.js – a partir da versão 10), a baseUrl aponta por padrão para o ambiente local de desenvolvimento, conforme demonstrado abaixo.

{
  "baseUrl": "http://localhost:3000"
}

Acima temos o arquivo de configuração antes da versão 10 do Cypress.

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000'
  }
})

Acima temos o arquivo de configuração a partir da versão 10 do Cypress.

Porém, os ambientes de homologação e produção possuem as seguintes URLs, respectivamente.

• https://example.homolog.com
• https://example.com

Imaginemos também que, no arquivo package.json, temos os seguintes scripts, para execução dos testes em cada ambiente específico:

"scripts": {
  "test": "cypress run",
  "test:homolog": "cypress run --config baseUrl=https://example.homolog.com --env environment=homolog",
  "test:prod": "cypress run --config baseUrl=https://example.com --env environment=prod"
}

No script test, os testes são executados contra o ambiente local, visto que a baseUrl não é sobrescrita.

Já nos scripts test:homolog e test:prod, a baseUrl é sobrescrita via linha de comando. Além disso, também passamos uma variável chamada environment (ambiente, em português), com um valor que identifica cada ambiente (homolog e prod).

Ou seja, podemos usar tal variável para nos ajudar.

Vamos ver como?

Localmente, podemos ter um arquivo não versionado (incluído no arquivo .gitignore) chamado cypress.env.json, o qual possuiria os seguintes valores.

{
  "LOCAL_USER": {
    "email": "local@user.com",
    "password": "the-password-of-the-above-user"
  },
  "HOMOLOG_USER": {
    "email": "some-user@example.homolog.com",
    "password": "the-password-of-the-above-user"
  },
  "PROD_USER": {
    "email": "another-user@example.com",
    "password": "the-password-of-the-above-user"
  }
}

Obs.: Recomendo também a criação de um arquivo chamado cypress.env.example.json, este sim sendo versionado, com valores exemplo, para que outros membros do time possam usar como modelo para a criação de seus próprios arquivos cypress.env.json, não versionados.

Obs. 2: Em um ambiente de integração contínua, tais valores (HOMOLOG_USER e PROD_USER) poderiam ser setados com o prefixo CYPRESS_, ou seja, CYPRESS_HOMOLOG_USER e CYPRESS_PROD_USER, com seus respectivos valores.

E agora que temos as credenciais, vamos para a implementação de um comando customizado que faz o login, com base no ambiente onde os testes estão sendo executados.

// cypress/support/commands.js

Cypress.Commands.add('login', () => {
  cy.log(`Logging into ${Cypress.env('environment') ? Cypress.env('environment') : 'local'} environment`)

  if (Cypress.env('environment') === 'homolog') {
    Cypress.env('user', Cypress.env('HOMOLOG_USER'))
  } else if (Cypress.env('environment') === 'prod') {
    Cypress.env('user', Cypress.env('PROD_USER'))
  } else {
    Cypress.env('user', Cypress.env('LOCAL_USER'))
  }

  cy.visit('/login')

  cy.get('[data-cy="emailField"]')
    .should('be.visible')
    .type(Cypress.env('user').email, { log: false })
  cy.get('[data-cy="passwordField"]')
    .should('be.visible')
    .type(Cypress.env('user').password, { log: false })
  cy.contains('button', 'Login')
    .should('be.visible')
    .click()
})

Ou seja, no comando customizado de login, dinamicamente setamos a variável user dependendo do ambiente passado via linha de comando no script do npm. Assim, podemos então fazer uso de tal variável nos comandos que digitam o email e senha do usuário.

Além disso, logamos no log de comandos do Cypress a frase “Logging into [environment] environment“, dependendo do ambiente em que os testes estejam rodando, onde caso a variável environment seja passada, usamos ela, caso contrário, o padrão é o valor local.

Ou seja, caso o valor da variável environment seja homolog, por exemplo, o seguinte seria “impresso” no log de comandos do Cypress:

Logging into homolog environment.

E o teste de login seria algo como o seguinte.

// cypress/integration/login.spec.js antes da versão 10 do Cypress
// ou cypress/e2e/login.cy.js a partir da versão 10 do Cypress

it('logs in', () => {
  cy.login()

  cy.get('[data-cy="avatar"]')
    .should('be.visible')
})

Como você pode ver, no teste propriamente dito, só chamamos o comando customizado cy.login, e ele “se vira” em autenticar na aplicação com as credenciais corretas.

É isso aí. Espero que tenhas gostado!

Para mais detalhes, recomendo a leitura da documentação oficial do Cypress.

---

Gostou do conteúdo? Deixa um comentário.

---

Este conteúdo foi traduzido para inglês e pode ser encontrado no DEV Community.

---

Ficou curioso(a) e quer aprender mais sobre automação de testes com Cypress? Conheça meus cursos no Udemy.

• Cypress básico
• Cypress intermediário
• Cypress avançado
• Boas práticas em automação de testes com Cypress
• Testes end-to-end com Cypress

---

👋  Até a próxima e bons testes!