E ainda assim proteger dados sensíveis, tais como usuário e senha
Recentemente, criei um vídeo na playlist cy.handsOn do 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"
}
Porém, os ambientes de homologação e produção possuem as seguintes URLs, respectivamente.
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.
{
"localUser": {
"email": "local@user.com",
"password": "the-password-of-the-above-user"
},
"homologUser": {
"email": "some-user@example.homolog.com",
"password": "the-password-of-the-above-user"
},
"prodUser": {
"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 (homologUser e prodUser) poderiam ser setados com o prefixo CYPRESS_, ou seja, CYPRESS_homologUser e CYPRESS_prodUser, 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('homologUser'))
} else if (Cypress.env('environment') === 'prod') {
Cypress.env('user', Cypress.env('prodUser'))
} else {
Cypress.env('user', Cypress.env('localUser'))
}
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
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 .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.
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
- Testes de regressão visual com Cypress e Percy (básico)
👋 Até a próxima e bons testes!
Cara, vai me ajudar muito essa dica, para configurar os ambientes em uma POC que estou fazendo aqui na empresa. Muito obrigado mesmo
Fico feliz em ajudar Quintiliano!
Sua orientação foi muito válida, e me ajusou a configurar meu ambiente aqui, sempre me intriguei, porque não conseguiria usar mais de uma configuração de ambiente, agora, sim, vai para frente, obrigado. Implementei agora a tarde e deu Certinho, sem problemas, ja vou começar a inserir mais variáveis que irei utilizar hehe.
Fico feliz que meu conteúdo te ajudou Frederico. Aproveito pra te convidar pra conhecer meu canal no YouTube https://www.youtube.com/c/talkingabouttesting. 👋
Walmyr, eu consegui configurar isto no meu teste, porém, eu só consigo rodar o teste com sucesso via linha de comando. Se eu rodo o comando “npx cypress open” para abrir o cypress e ver em tempo real o teste rodando, o teste falha, e eu tomo um erro na parte ali do “nome”. Error: Cannot read properties of undefined (reading ‘nome’)
Eu só consigo fazer o teste rodar com sucesso via linha de comando com esse tipo de configuração?
Oi Nathália,
Por favor, faça um commit do seu código (com todas suas mudanças), publique no GitHub (com um git push) e compartilhe o link do seu repositório para que eu possa baixar o código em meu computador e tentar reproduzir o problema. Dessa forma, mais facilmente poderei te ajudar.
Fico no aguardo.
Ei Walmyr, seu blog sempre ajudando demais!
Porém essa configuração de vários ambientes (a do vídeo), para versão 11 do cypress, não funciona mais, até tentei adaptar, sem sucesso.
Alguma chance de lançar uma atualização para versões mais recentes?
Muito obrigada
O que você quer dizer com não funcionará mais? A idéia é a mesma, deve funcionar sim. Por qual motivo não funcionaria?
Se não funcionou pra você, já pensou que talvez tenha feito algo errado, ou que algum detalhe esteja faltando?
Acabei de testar com a versão 12.5.1 e funcionou perfeitamente.
Oi, Walmir. Tudo bem? Primeiramente muito obrigado pelo conteúdo.
Tentei utilizar essa mesma lógica mas colocando URLs diferentes dentro do .env, ficou assim:
Cypress.Commands.add(‘loginAPI’, () => {
if (Cypress.env(‘environment’) === ‘homolog’) {
Cypress.env(‘URL’, Cypress.env(‘url_local’))
Cypress.env(‘user’, Cypress.env(‘homologUser’))
} else if (Cypress.env(‘environment’) === ‘prod’) {
Cypress.env(‘URL’, Cypress.env(‘url_prod’))
Cypress.env(‘user’, Cypress.env(‘prodUser’))
} else {
Cypress.env(‘URL’, Cypress.env(‘url_local’))
Cypress.env(‘user’, Cypress.env(‘localUser’))
}
Apesar disso não funcionou, ele simplesmente pega somente a primeira URL do env e desconsidera as outras.
Consegue me dar uma luz de como trabalhar com URLs diferentes? No caso não coloco só uma BASE_URL pois tenho diferentes URL pra testar front e back.
Agradeço sua ajuda. Abraço
Opa Lucas, o blog post demonstra uma solução simples para lidar com várias URLs, que é sobrescrever a mesma via linha de comando (ex. cypress run –config baseUrl=https://example.com). Por qual motivo fazer diferente?
Opa, Walmir. No caso eu tenho duas URLs dentro do mesmo ambiente (front e back).
Meu .env está dessa forma, por exemplo:
{
“url_local”: {
“front”: “http://localhost:4200”,
“back”: “http://localhost:8080”
},
[…]
Tentei de todas as formas aqui mas não consegui setar o script para a URL correta. Teria alguma forma?
Desde já obrigado pela ajuda e atenção!
Lucas, neste caso, te convido a conhecer meu serviço de revisão de código. Se tiver interesse em contratar posso te ajudar.
https://talkingabouttesting.com/servicos/code-review-as-a-service/