Hoje em “pitadas de Cypress”, aprenda como proteger credenciais de acesso, tais como usuário e senha
O cenário é o seguinte. Temos um teste end-to-end para a funcionalidade de login, e vários outros testes também dependem do usuário estar logado como pré-condição.
Porém, é uma má prática versionar credenciais, tais como usuário e senha.
Uma alternativa que já usei diversas vezes para resolver tal problema é o uso do arquivo cypress.env.json (qundo trabalhando em ambiente local de desenvolvimento).
Tal arquivo permite armazenarmos dados sensíveis (por exemplo), porém não o versionamos (ou seja, ele é incluido no arquivo .gitignore).
Vejamos um exemplo prático.
O arquivo cypress.env.json seria assim:
{ "user_name": "admin", "user_password": "s3creT-p@ssw0rd" }
Lembre-se que este arquivo somente estaria disponível em meu computador. E se outros(as) desenvolvedores(as) utilizarem outro usuário e senha, nos computadores deles(as) as credenciais estariam diferentes, mas também não versionadas.
E o teste de login seria assim:
describe('Login', () => { it('com sucesso', () => { cy.visit('https://exemplo.com/login') cy.get('#user') .type(Cypress.env('user_name')) cy.get('#password') .type(Cypress.env('user_password')) cy.contains('Login').click() cy.get('.navbar-top .avatar') .should('be.visible') }) })
Tada! 🎉
Dessa forma, não exponho tais dados sensíveis, e meus testes continuam conseguindo fazer login.
Além disso, tal abordagem nos dá a vantagem de poder expor tais credenciais como variáveis de ambiente (pré-fixadas por CYPRESS_ ou cypress_) em serviços de integração contínua, os quais executam os testes contra outros ambientes que não o nosso ambiente local.
Ou seja, os dados sensíveis ficam protegidos, e conseguimos rodar os mesmos testes em diferentes ambientes (local, homologação, produção, etc.) 💯
Por fim, caso você queira proteger que sua senha não “vaze” na execução dos testes em modo interativo em seu ambiente local, passe a opção { log: false } como segundo argumento do .type() e tal comando não será listado na lista de comandos do Cypress runner (veja abaixo).
describe('Login', () => { it('com sucesso', () => { cy.visit('https://exemplo.com/login') cy.get('#user') .type(Cypress.env('user_name')) cy.get('#password') .type(Cypress.env('user_password'), { log: false }) cy.contains('Login').click() cy.get('.navbar-top .avatar') .should('be.visible') }) })
Este conteúdo foi traduzido para inglês e pode ser encontrado no DEV Community.
Estou curioso. O que está achando da série?
Aguardo teu feedback.
Quer aprender automação de testes com Cypress na prática? Conheça meus cursos na Escola Talking About Testing, ou no Udemy.
Esta serie está muito bacana… Assim vamos pegando novas coisas aos poucos.. Obrigado por compartilhar
Obrigado pelo feedback Georgem!
É esse mesmo o intuito.
Interessante. Eu costumo usar o readFile com um arquivo json que fica no C: da minha máquina. Mas esse modo parece melhor.
Interessante. Obrigado por compartilhar.
Quem sabe da orixá vez que precisar lidar com isso resolva dessa forma e me avisa como foi a experiência.
Precisei disso hoje, lembrei das pitadas e vim conferir, práticas e objetivas! Já vou aplicar.
🙌
Olá. Como eu faço quando eu preciso testar mais de um usuário usando o arquivo env.cypress? Por exemplo, eu preciso ter a opção com informações incorretas e incompletas para fins de teste e também preciso de uma massa de teste ok para fazer o teste do caminho feliz. E já tentei colocar mais de um exemplo e não deu certo.
Oi Jássica, recomendo ler a documentação oficial do Cypress.env (https://docs.cypress.io/api/cypress-api/env) para entender melhor como usar tal funcionalidade.