Automação do Zero: Como Criar Fixtures Personalizadas no Playwright | Dicas do Gabs

O papel das fixtures no Playwright

A criação de testes automatizados profissionais exige mais do que saber clicar em botões e preencher formulários. Um dos principais diferenciais entre um teste amador e um teste de nível de produção está na forma como os dados são preparados e entregues para cada execução. No contexto do Playwright, o mecanismo de fixtures oferece exatamente essa capacidade: isolar a montagem de dados e estado do teste em funções reutilizáveis que rodam automaticamente antes de cada cenário. Neste episódio da série Automação do Zero, o canal Dicas do Gabs mostra como estruturar essa camada de preparação de dados com Faker.js, criando uma base sólida para testes de interface confiáveis e de fácil manutenção.

O episódio parte de um contexto já iniciado em vídeos anteriores, no qual o Faker.js foi instalado no projeto. A ideia agora é transformar a geração de dados aleatórios em um sistema organizado, com arquivos dedicados e funções bem definidas. Essa organização não é apenas estética: ela muda completamente a legibilidade do código de teste, reduz a duplicação e prepara o terreno para a separação entre dados estáticos e dinâmicos, dois conceitos centrais da aula.

Centralizando a geração de dados no testData.js

O primeiro passo mostrado no vídeo é a criação do arquivo testData.js, responsável por centralizar toda a geração de dados da suíte. Em vez de espalhar chamadas ao Faker por diversos arquivos de teste, a equipe concentra nesse módulo as funções e constantes relacionadas aos dados. Essa prática segue o princípio de responsabilidade única e facilita a manutenção: quando o formato de um e-mail ou telefone precisar mudar, será necessário alterar apenas um local.

Dentro do testData.js, a principal função apresentada é a gerarUsuario(), que usa o Faker para devolver um objeto completo de usuário a cada chamada. Esse objeto contém nome, email, telefone e senha, todos gerados de forma aleatória e única. A vantagem de ter um gerador de usuário centralizado é enorme: cada teste que precisar de credenciais ou dados de cadastro pode invocar a mesma função, sem duplicar lógica de geração e sem correr o risco de inconsistência entre os cenários.

Diferença entre dados estáticos e dinâmicos

Um ponto de destaque do conteúdo é a separação clara entre dados estáticos e dinâmicos. Dados dinâmicos são aqueles que variam a cada execução, como nome, e-mail e telefone gerados pelo Faker. Dados estáticos, por outro lado, são informações que permanecem constantes, como os campos de um livro usado em testes de cadastro de produto. O vídeo mostra a criação de uma variável chamada dadosPadrao, que armazena esses dados fixos de livro.

Essa separação tem implicações práticas importantes. Dados estáticos podem ser usados para validar valores esperados de forma determinística, enquanto dados dinâmicos servem para simular usuários diferentes a cada rodada. Em suítes grandes, essa organização reduz o acoplamento entre testes e facilita a leitura do código, pois cada tipo de dado está explicitamente identificado no arquivo testData.js.

Função gerarUsuario com Faker.js

A função gerarUsuario() é detalhada por volta dos quatro minutos e funciona como um gerador de massa de teste. Ao ser invocada, ela retorna imediatamente um objeto com todas as propriedades necessárias para um usuário de teste: primeiro nome, e-mail válido, telefone e senha. O uso do Faker.js garante que os valores sejam realistas e variados, o que é importante quando se deseja testar cenários de cadastro repetidos sem colidir com restrições de unicidade no banco de dados.

Um detalhe sutil da implementação é a composição do e-mail a partir do nome gerado, prática comum para garantir que o endereço seja coeso e fácil de rastrear nos logs durante a depuração. A senha, por sua vez, costuma ser mantida simples para facilitar a digitação manual quando necessário, ou então gerada com regras específicas do sistema sob teste. O vídeo enfatiza que a função deve ser chamada dentro do contexto correto, preferencialmente via fixtures, para que cada teste receba uma instância nova de usuário.

O conceito de fixtures no Playwright

A partir dos dez minutos, o vídeo se aprofunda no conceito de fixtures no Playwright. Uma fixture é uma abstração que permite injetar dependências nos testes sem que a pessoa que escreve o cenário precise se preocupar com os detalhes de inicialização. O Playwright usa o método test.extend() para criar um novo objeto de teste com fixtures personalizadas, que são executadas automaticamente antes de cada teste e, se necessário, realizam limpeza depois.

A explicação começa com o test padrão do Playwright, aquele que já traz fixtures embutidas como page, context e browser. Ao usar test.extend(), é possível adicionar novas propriedades a esse objeto, como usuario, livro e senha. O resultado é que, dentro de qualquer teste que use esse test estendido, as propriedades estarão disponíveis por injeção de dependência, exatamente como acontece com a fixture page.

Criando o fixtures.js com test.extend

O arquivo fixtures.js é apresentado como o ponto de integração entre o testData.js e o runner de testes. Nele, test.extend() recebe um objeto cujas chaves são os nomes das fixtures e cujos valores são funções assíncronas ou síncronas que retornam o dado desejado. Para a fixture usuario, por exemplo, a função simplesmente chama gerarUsuario() e retorna o objeto gerado. Para livro, retorna os dadosPadrao importados do testData.js. Para senha, pode retornar tanto um valor estático quanto dinâmico, dependendo do cenário.

Uma das vantagens de usar fixtures é que o Playwright trata o ciclo de vida desses valores: se uma fixture retornar um recurso que precisa ser liberado, basta usar a estrutura try/finally dentro da função, e o Playwright garante que a limpeza será executada ao final do teste. No caso do vídeo, as fixtures são simples e retornam objetos de dados, então não há necessidade de limpeza explícita, mas o mecanismo fica explícito para quem quiser evoluir o projeto.

Como o teste consome as fixtures

Com o fixtures.js configurado, o teste final fica extremamente limpo. Em vez de importar Faker diretamente, chamar gerarUsuario e repetir a lógica de dados, o teste declara as fixtures como parâmetros na função do cenário. O Playwright identifica esses parâmetros, executa as fixtures correspondentes e entrega os valores prontos para uso dentro do corpo do teste. O vídeo exemplifica isso com a recepção de usuario, livro e senha como argumentos.

Essa abordagem permite que a pessoa responsável pelo teste foque exclusivamente na lógica de interação com a interface: preencher o formulário de cadastro, submeter, validar mensagens de sucesso ou erro. A geração de dados fica encapsulada na camada de fixtures, o que aumenta a legibilidade e reduz a chance de erro por esquecimento de alguma etapa de preparação. Esse padrão é amplamente adotado em equipes de qualidade que mantêm suítes grandes de regressão.

Resumo e preparação para Page Objects

No encerramento, o vídeo faz um recap dos arquivos criados e das funções implementadas, reforçando a importância de separar responsabilidades: testData.js gera dados, fixtures.js entrega dados, e o teste consome dados. A menção ao próximo episódio indica que o passo seguinte será usar esses dados dentro de um Page Object, com seletores testados no DevTools. Isso conecta a aula atual a um fluxo maior de aprendizado em automação de testes de interface.

Para quem acompanha a série Automação do Zero, o conteúdo deste episódio representa um salto de maturidade no código. A simples adoção de fixtures com Faker.js e test.extend() transforma a suíte de testes em um sistema coeso, preparado para crescer com novos cenários e novos dados. A base construída aqui é exatamente o que permitirá a implementação de Page Objects robustos nos próximos vídeos.