Índice
- Desenvolvedora
- Tecnologias utilizadas
- Configuração para rodar o projeto
- Repositórios Jest e Playwright
- Outras documentações
- Versionamento, code review e padronização
- Futuras Melhorias e Sugestões
- Agradecimentos
| Aline Espindola 💻🎨 | 
Antes de iniciar, certifique-se de ter o Node instalado.
- Clonar o repositório:
git clone https://github.com/tagplus-qa-lab/qa-junior-playwright-api.git
cd qa-junior-playwright-api- Copiar o arquivo de exemplo de variáveis de ambiente:
cp .env.example .envEsse arquivo já vem configurado com o link padrão do site GoRest, utilizado nos testes automatizados. Caso queira validar outro ambiente (como o de homologação ou produção), basta editar o valor da variável BASE_URL dentro do arquivo .env e inserir o novo endereço.
- Criar token no seu .env. Você gera a partir do site do GoRest
GOREST_TOKEN=Seu Token- Instalar as dependências do projeto:
npm i- Instalar os navegadores necessários do Playwright:
npx playwright install- Executar todos os testes:
npm testEmbora este projeto tenha repositórios com Playwright API e Jest API, ambos são utilizados apenas para testes de integração.
- 
Playwright: utilizado inicialmente para validação de fluxo completo de APIs, mas sua principal força é em testes E2E com UI. Para testes de integração de backend, ele acaba sendo mais pesado e menos prático. 
- 
Jest: é a ferramenta preferida para testes de integração neste projeto, pois oferece: - Execução mais rápida de testes de APIs e funções isoladas.
- Manutenção mais prática, sem depender de navegador ou UI.
 
Ter repositórios com ambas as ferramentas demonstra versatilidade e conhecimento em diferentes stacks de teste.
Além de Jest e Playwright, a experiência em frameworks como pytest reforça a capacidade de escolher a ferramenta certa para cada tipo de teste, garantindo eficiência e cobertura adequada.
No projeto, algumas documentações adicionais estão disponíveis para referência e melhor organização dos testes e funcionalidades.
- Toda a documentação referente aos testes automatizados de integração está localizada na pasta /docs.
- Controle de versão: Git + GitHub
- Versão inicial: 1.0.0
- Todos requisitos cumpridos e documentados
 
- Versão: 1.0.1
- Correção da pipeline
 
- Versão: 1.0.2
- Novas documentações
 
- Todas as alterações foram commitadas e revisadas via pull request para manter a consistência do código, além de usar o Kanban para fins de organização de tarefas.
Adotei o seguinte padrão:
- playwright-api-[id-da-tarefa]/
Utilizei o padrão Conventional Commits para manter o histórico limpo e informativo:
📌 Nota: Escrevo os verbos no imperativo. Isso descreve o que o commit faz, como uma instrução ou comando, por exemplo: "Adiciona", "Corrige", "Ajusta".
| Tipo | Descrição | Exemplo de Mensagem | 
|---|---|---|
| feat | Adição de nova funcionalidade | feat(playwright-api-12): adiciona mock do usuário | 
| fix | Correção de bugs | fix(playwright-api-14): corrige erro de exibição dos dados dos posts | 
| docs | Atualização ou criação de documentação | docs(playwright-api-12): atualiza README com padrões | 
| refactor | Refatorações de código sem mudanças de comportamento | refactor(playwright-api-12): simplifica lógica do utils | 
| test | Adição ou atualização de testes | test(playwright-api-13): adiciona testes para componente Header | 
| chore | Atualizações gerais (ex.: dependências, build) | chore(playwright-api-54): atualiza versão do Playwright | 
| perf | Melhorias de performance | perf(playwright-api-12): otimiza carregamento de dados | 
| revert | Reversão de um commit anterior | revert(playwright-api-11): remove validação do nome do usuário | 
Durante o desenvolvimento deste projeto, identifiquei diversas oportunidades de evolução e aprimoramento para torná-lo ainda mais robusto, escalável e aderente a boas práticas de qualidade de software.
- Adicionar novos tipos de testes: incluir testes como unitários para ampliar a cobertura e garantir estabilidade.
- Centralizar repositórios de testes: criar um repositório principal que englobe os três repositórios de testes existentes (frontend e API), permitindo clonar e executar todas as suítes de testes com um único comando.
- Esse repositório também poderia conter:
- Documentação unificada
- Scripts automatizados de execução
- Relatórios consolidados
 
 
- Esse repositório também poderia conter:
- Logging: incluir logs estruturados para diferentes níveis de severidade:
- Info: eventos importantes ou etapas concluídas com sucesso.
- Warning: alertas sobre comportamentos inesperados que não quebram o teste.
- Error: falhas críticas ou exceções, com rastreamento detalhado da origem do problema.
 
- Criar validadores personalizados: incluir validações automáticas de campos como:
- E-mail (formato válido)
- Senha (mínimo de caracteres, regras de negócio, complexidade)
- Campos obrigatórios e regras condicionais
 
- Expandir a cobertura de testes de integração:
- Testar funcionalidades adicionais, como ordenação de produtos, filtros e fluxos alternativos de login.
- Garantir que as principais jornadas do usuário estejam protegidas contra regressões.
 
- Notificações automáticas de falhas: implementar envio de e-mail via NodeMailer na pipeline sempre que ocorrerem erros críticos nos testes, permitindo resposta rápida e acompanhamento das falhas.
Essas sugestões representam o próximo passo natural para aprimorar a qualidade do projeto, aumentar a confiabilidade dos testes e tornar a manutenção mais eficiente e escalável.
Gostaria de agradecer a TagPlus pela oportunidade de participar deste processo seletivo.
Agradeço também a todos que irão avaliar o projeto, revisar código e fornecer feedbacks valiosos.
Foi uma experiência enriquecedora aplicar boas práticas de desenvolvimento e testes automatizados neste projeto.