DEV Community: Renato O. Nunes

Playwright: Using Cognito to Log In for Your E2E Tests

Renato O. Nunes — Thu, 26 Jun 2025 13:21:37 +0000

Some time ago, I started looking for a better way to handle login in my E2E tests using Playwright.

At the time, I was using a setup test that executed a basic login flow (opening the app and entering a username and password). After that, I’d save the storageState to a .json file and use it in my tests like this:

test.use({ storageState: './storage/userStorageState.json' });

There’s nothing particularly special about this setup. It's actually one of the recommended approaches in the Playwright documentation.

The issue I ran into was that, even though this login test only ran once at the start of the test suite, it still took some time. Since I have several tests that require different users, this delay became a bit annoying.

Another problem was that occasionally the storageState would become invalid, and I’d have to run the setup again.

At other companies, I used to handle this more efficiently: just make an API request, get the auth token, inject it into the session, and start testing. But in this case, the application needed a lot more than just a token, and some of it came from Cognito, and the rest had to be pulled from my backend.

So, if your app also uses Cognito and you're facing similar issues, the example below might be helpful:

After these changes, our login execution time dropped from over a minute to just 9 seconds. We had 8 users that needed to be authenticated before running the tests.

require('dotenv').config();
const { Auth } = require('aws-amplify');
const fs = require('fs');
const path = require('path');
const axios = require('axios');
const { getBaseURL } = require('./env-config');
const { getCognitoConfig } = require('./cognito-pull-config');
const users = require('./users-config');

async function loginCognitoSetup() {
  const { appURL, apiURL } = getBaseURL();

  const {user_pool_id, frontend_client_id} = getCognitoConfig();

  const awsconfig = {
    aws_user_pools_id: user_pool_id,
    aws_user_pools_web_client_id: frontend_client_id,
  };

  Auth.configure(awsconfig);

  const makeKey = (cognitoUser, name) =>
    `CognitoIdentityServiceProvider.${cognitoUser.pool.clientId}.${cognitoUser.username}.${name}`;

  for (const [key, { username, password }] of Object.entries(users)) {
    try {
      const cognitoUser = await Auth.signIn(username, password);

      const { data: cognitoMonolithUser } = await axios.get(
        `${apiURL}/api/cognitouser`,
        {
          headers: {
            Authorization: `Bearer ${cognitoUser.signInUserSession.idToken.jwtToken}`,
          },
        }
      );

      const storageState = {
        cookies: [],
        origins: [
          {
            origin: appURL,
            localStorage: [
              {
                name: makeKey(cognitoUser, 'idToken'),
                value: cognitoUser.signInUserSession.idToken.jwtToken,
              },
              {
                name: 'user',
                value: JSON.stringify(cognitoMonolithUser),
              },
              {
                name: 'isAuth',
                value: 'true',
              },
              {
                name: 'company',
                value: JSON.stringify(cognitoMonolithUser.company),
              },
              {
                name: 'tokens',
                value: JSON.stringify(cognitoUser.signInUserSession),
              },
              {
                name: makeKey(cognitoUser, 'refreshToken'),
                value: cognitoUser.signInUserSession.refreshToken.token,
              },
              {
                name: makeKey(cognitoUser, 'clockDrift'),
                value: '0',
              },
              {
                name: 'amplify-signin-with-hostedUI',
                value: 'false',
              },
              {
                name: makeKey(cognitoUser, 'accessToken'),
                value: cognitoUser.signInUserSession.accessToken.jwtToken,
              },
              {
                name: `CognitoIdentityServiceProvider.${cognitoUser.pool.clientId}.LastAuthUser`,
                value: cognitoUser.username,
              },
              {
                name: makeKey(cognitoUser, 'userData'),
                value: JSON.stringify(cognitoUser.attributes),
              },
            ],
          },
        ],
      };

      const fileName = `${key}StorageState.json`;

      const filePath = path.resolve(__dirname, '..', 'storage' , fileName);

      fs.writeFileSync(filePath, JSON.stringify(storageState, null, 2));
      console.log(`Storage created to ${key} (${username}) → ${fileName}`);
    } catch (error) {
      console.error(`Error to create the user ${username}:`, error.message);
    }
  }
}

module.exports = loginCognitoSetup;

⚠️ The attributes used in the code above were required for the specific app I was working with. That doesn't mean you'll need all of them, and depending on your setup, you might even need additional ones. That’s why it's crucial to understand exactly how your app manages authentication.

You’ll notice the code above expects some values from files, like appURL, apiURL, username, password, etc.

That’s because, in addition to handling Cognito logins, I also needed the project to support multiple environments. It might not be the most elegant solution out there, but it works and it’s fairly organized. ;)

At the ./config level, create a file called users-config.js, and inside it, add:

require('dotenv').config();

module.exports = {
  admin: {
    username: process.env.MY_USER,
    password: process.env.MY_PASS,
  }
};

Create another file in the same directory called env-config.js:

const environments = {
  automation: {
    app: 'https://localhost.com',
    api: 'https://api.locahost.com',
  }
};

function getBaseURL() {
  const ENV = process.env.NODE_ENV || 'dev';
  const config = environments[ENV];

  if (!config) {
    console.error(`Environment '${ENV}' not found!`);
    process.exit(1);
  }

  return {
    ENV,
    appURL: config.app,
    apiURL: config.api, 
  };
}

module.exports = { getBaseURL };

Once that's done, you just need to add the login-cognito-setup.js file as the setup script for your tests.

In your playwright.config.js file, add this line:

 {
   name: 'setup',
   testMatch: '**/*.cognito.js',
 },
 {
   name: 'e2e-tests',
   testMatch: '**/*.spec.js',
   dependencies: ['setup'],
 },

🔖 One thing to note: we didn’t need to change the test.use calls in our test files. That’s because we’re saving the new storageState to the same location as before, so everything continues to work as expected.

To run just the login setup:

 "test:login-setup": "NODE_ENV=local playwright test --project=setup --config=playwright.config.js"

To run login + tests:

 "test:local": "NODE_ENV=local playwright test --project=e2e-tests --config=playwright.config.js"

Testes de regressão visual com Cypress + Percy: CI com Github Actions

Renato O. Nunes — Thu, 06 May 2021 23:40:03 +0000

Integração Percy + Github + Actions

Por último, mas não menos importante, vamos fazer a integração dos nossos testes + percy com o Github Actions.

Antes de prosseguir, garanta que seu projeto já esteja no github.

1) Crie uma Secret Token no seu projeto com o nome PERCY_TOKEN. O Conteúdo será o token que você pode pegar lá na plataforma do Percy, como já vimos anteriormente.

2) Crie um GitHub Actions novo. Se você não sabe criar, basta ir no seu projeto, em Actions, e clicar na opção Set up a workflow yourself

3) Configure conforme o código abaixo:

https://github.com/r0nunes/cypress-percy/blob/main/.github/workflows/percy.yml

Feito isso, basta realizar o commit.

Clicando novamente na aba Actions, você verá que nossa build foi executada com sucesso. De agora em diante, qualquer pull_request que houver na branch 'main', o nosso Github Actions será executado e teremos uma nova build lá na plataforma do Cypress.

Bonus#1

Da forma que fizemos, só vamos ter a integração contínua rodando nossos testes, porém se houver alguma diferença nas imagens, a build não irá falhar. Para que isso ocorra, basta fazer a integração do Percy com o seu repositório do github.

1) Vá no seu projeto, na plataforma Percy. Clique na opção Integrations¹ e depois clique na opção Connect to Github.

Clique na opção Install Github App. Na janela que abrir para liberar permissão, selecione todos os repositórios ou, caso deseje, selecione o repositório do seu projeto em questão. Após isso clique em Install.

Feito isso, a partir de agora quando você fizer um pull_request de uma branch, o seu Actions irá executar juntamente com o job do percy, onde qualquer diferença encontrada irá travar a build.

Para liberar, ou você ajustar a aplicação para que fique como estava antes, ou, caso seja uma nova feature, você deve ir na plataforma do Percy, e na build que acabou de executar, aprovar o novo snapshot como sua baseline.

Você não precisa fazer mais nada além disso, o Percy automaticamente irá mandar uma requisição para o github e rodar o Actions novamente, liberando para o merge.

Conclusão

Com base nesse artigo/tutorial, espero por ajudar todos vocês que queiram implementar mais uma camada de testes automatizados que traz um grande ganha na qualidade do produto.

❗ Ponto importante.

Essa camada de testes estão basicamente na mesma camada de testes UI. Logo, são testes que podem ter um custo/tempo alto na hora da execução. Portanto, a minha sugestão é para que analise bem quais são as páginas/funcionalidades mais importantes da sua aplicação, e não saía automatizando todas as telas que você tiver pois isso não irá te trazer ganhos.

💻 Link da aplicação: https://ronunes-proffyaglz.netlify.app/
📂 Link do repositório: https://github.com/r0nunes/cypress-percy
📄 Documentação do Percy: https://docs.percy.io/docs

Testes de regressão visual com Cypress + Percy: Analisando os diffs

Renato O. Nunes — Thu, 06 May 2021 23:22:45 +0000

Execução com diffs

Até o momento já conseguimos executar o teste, enviar o snapshot para a plataforma Percy e realizar o auto-approve. Com isso, já temos nossa baseline.

Baseline serão seus snapshots válidos, ou seja, aqueles que devem ser considerados como certo. Serão com base neles que toda execução nova será comparada.

Agora iremos alterar algo na aplicação e rodar os testes novamente para que o Percy identifique as inconsistências.

Vamos remover a frase Treinando testes de regressão visual com Percy da nossa aplicação e rodar o teste novamente.
Como já temos uma imagem aprovada como baseline, tudo que precisamos fazer nesse momento é executar o teste novamente, já com a nossa aplicação sem a frase.

Acessar o link da build gerada no final da execução: https://percy.io/4c61c7c3/tutorial/builds/10231561

E olha só, já podemos ver que o Percy identificou inconsistências na nova imagem com base na imagem que temos salva.

Versão Desktop
Versão mobile

A partir daí exitem algumas ações a serem tomadas, como:

Solicitar alterações do produto,impedindo que o teste seja salvo como "correto" até que a correção seja realizada. Para isso basta clicar no ponto de exclamação e colocar um comentário (não é obrigatório colocar) do porque está solicitando a request.

Você também pode simplesmente aprovar essa imagem como a nova baseline, considerando que a frase deve ser removida de fato. Para isso, basta clicar no sinal de ok.

No caso acima, fizemos apenas para uma imagem, pois temos apenas um testes. Claramente em seu projeto, haverá mais testes e consequentemente mais snapshot para validar. Caso queira aprovar todos os snapshots como corretos, basta clicar no botão Approve Build que toda sua build será aprovada.

No próximo capítulo iremos ver integração contínua com Github Actions.

Testes de regressão visual com Cypress + Percy: Execução na plataforma Percy

Renato O. Nunes — Thu, 06 May 2021 23:17:19 +0000

Executando seus testes na plataforma Percy

Bom, já que temos certeza que os nossos testes não possuem nenhum erro e estão executando perfeitamente em nosso ambiente local, é hora de fazer a integração com o ambiente do Percy Cloud.

Para isso, você deve executar via CLI (command line) o comando:

npx percy exec -- cypress run

Uma vez que temos nossa PERCY_KEY exportada em nosso ambiente, quando passamos o comando percy em nossa execução, automaticamente faremos a sincronização com a plataforma Percy.

No final da execução do teste, você deverá ter o resultado abaixo, caso ocorra tudo certo.

O próximo passo é acessar a plataforma do Percy. Copie o link que é gerado no final do teste e acesse no seu navegador de preferência.

Ex.: No nosso caso o link foi: https://percy.io/4c61c7c3/tutorial/builds/10214530

Conhecendo a plataforma Percy

Assim que você acessar o link acima e fizer login na plataforma, você será direcionado para a build que foi executada na sua máquina e com os testes que foram executados.

Veja que já temos um snapshot da tela home da nossa aplicação, exatamente como pedimos para o nosso teste fazer.

Alguns detelhes que precisamos saber antes de prosseguir:

1) Quando realizamos o merge dos testes diretamente na master/main, o Percy irá aprovar automaticamente os snapshot.

O que você quer dizer com aceito automaticamente Renato? O que eu quero dizer é que se você já tiver uma imagem como baseline, ele irá substituir pela imagem nova. E se você não tiver, a plataforma irá considerar a imagem nova como baseline, ok?

A solução para isso é simplesmente sempre trabalhar em uma branch diferente da master/main, como normalmente já fazemos no dia a dia, ou ir nas configurações do projeto e alterar para que o auto-approve seja realizado em uma branch diferente. Particularmente, eu não altero essa configuração.

Mas, caso queira, basta ir em no seu projeto > Settings e procurar por Branch Settings.

2) Por padrão, a sua execução é realizada nos navegadores Chrome e Firefox, e nas resoluções 375px (mobile) e 1280px (Desktop). Você pode alterar os modos para verificar como fica a sua aplicação clicando nas opções acima da imagem localizada ao lado direito. Também é possível executar seu teste com uma resolução especifica, porém não iremos ver agora.

Exemplo do nosso snapshot na resolução 375px

Por hora, apenas o Chrome e Firefox são aceitos pelo Percy. Mais detalhes veja em: https://docs.percy.io/docs/cross-browser-visual-testing

No próximo tópico, iremos analisar as diferenças encontradas nos snapshots.

Testes de regressão visual com Cypress + Percy: Criando seu primeiro teste

Renato O. Nunes — Thu, 06 May 2021 23:09:46 +0000

Criando seu primeiro teste

Bom, dado que já temos o percy instalado em nosso projeto, faremos a criação do nosso primeiro teste de regressão visual.

Dentro do diretório cypress/integration crie um arquivo chamado visual.spec.js. Abra o seu teste e coloque o conteúdo abaixo:

Entendendo o que fizemos no teste:

cy.visit('https://ronunes-proffyaglz.netlify.app/');

Visitamos a página inicial da nossa aplicação;

cy.get('.hero-image').should('be.visible');

Verificamos se a imagem referente ao class (.hero-image) está visível.

cy.percySnapshot();

Por fim, realizamos a chamada do Percy para executar o snapshot. Lembrando que a execução é realizada em toda a área da página que você estiver, que no nosso caso é a home.

Exececute seu teste e você deverá ter o mesmo resultado abaixo:

Mas pandinha 🐼, cadê os snapshots? Calma lá jovens!

A forma que fizemos acima permite executar os seus testes sem ter que realizar integração com a plataforma do Percy, o que ao contrário, faria com que cada teste seu que viesse a falhar, seria descontado do número de execuções que você tem no plano free.

Não queremos perder essas execuções free que temos por bobeira né?

No próximo tópico iremos ver como executar os testes integrando na plataforma do Percy.

Testes de regressão visual com Cypress + Percy: Configuração

Renato O. Nunes — Thu, 06 May 2021 23:04:29 +0000

Já ouviu falar sobre testes de regressão visual? Não?

Testes de regressão visual são basicamente testes de alto nível que conseguem identificar qualquer alteração visual de um sistema. Para que isso ocorra, o teste realiza um snapshot da página em questão, e realiza uma comparação
com uma versão estável, conhecida como baseline.

O que vamos ver nessa série de artigos é como fazer testes de regressão visual utilizando os frameworks Cypress e Percy.

Pré-requisitos

Ter o cypress instalado e configurado em sua máquina. No nosso caso, usaremos a versão mais recente (7.x), mas funcionará nas versões anteriores também.
Ter um cadastro no https://percy.io (Não se assuste quando for direcionado para o browserstack. Você terá que fazer o login por lá mesmo).
Ter o PERCY_TOKEN como variável de ambiente. (Caso não tenha, basta acessar o portal do percy.io e criar um novo projeto que você verá o token). Se você já tiver o projeto e não sabe seu token, acesse seu projeto do percy, vá na opção Project Settings. Lá você achará seu token.

Configuração

1) Adicione seu PERCY_TOKEN nas variáveis de ambiente.

Unix

export PERCY_TOKEN="<your token here>"

Windows

set PERCY_TOKEN="<your token here>"

2) Acesse o repositório do seu projeto Cypress através do terminal (Windows/Unix) e instale a dependência do Percy:

npm install --save-dev @percy/cli @percy/cypress

Obs: Lembre-se que a versão do Node deve ser no mínimo a 12.0.x. Caso contrário, ocorrá erro no seu console na hora de instalar as dependências acima.

3) Agora precisamos importar o package do Percy no projeto. Para isso, adicione a linha abaixo no seu arquivo Cypress/Support/index.js.

import '@percy/cypress';

[Cypress] - Executando testes com múltiplas tags

Renato O. Nunes — Wed, 24 Feb 2021 02:37:24 +0000

Olá pandolfos(as)!

Tempos atrás eu estava automatizando alguns testes em um projeto pessoal, cujo tive contato com uma lib chamada cypress-select-tests.

Basicamente, essa lib permite executar os testes baseado em Tags, o que facilita muito quando você quer executar apenas alguns testes que contenham determinada tag.

Até aí legal né? Porém, o que essa lib e tampouco o cypress em si não permitem, é rodar múltiplas tags ao mesmo tempo.

Eis vos deixo a mágica!

Instalar a lib cypress-select-tests em seu projeto.

npm install --save-dev cypress-select-tests

No seu projeto, abra o arquivo index.js que está dentro do diretório cypress/plugins e coloque o código abaixo.
Nos seus testes, inclua suas tags. No nosso caso, vamos usar as tags @contract e @healthcheck.

Feitas as configurações, basta executar o comando abaixo para que seus testes sejam executados conforme as tags selecionadas:

Note que não há espaço na separação das tags. Se tiver, ocorrerá um erro no console Cannot read property 'split' of undefined.

No meu projeto, o resultado foi conforme a imagem abaixo.

Se notarmos, na minha spec booking.spec.js eu tenho 9 testes, sendo que destes, apenas 1 passou e o restante foi ignorado, visto que não possuem a tag @contract.

Na minha segunda spec ping.spec.js, eu tenho 6 testes, sendo que destes, apenas 1 passou e o restante foi ignorado, visto que não possuem a tag @healthcheck.

É isso pessoal, espero que ajude vocês!

Who am I?: Renato O. Nunes.
Who helped me?: Denis Fevereiro, Samuel Lucas