Api playwright 3/documentation

README.md

@@ -1 +1,143 @@
-# qa-junior-playwright-api
+# Documentação do Projeto de Testes Automatizados para GoRest
+
+Índice
+1. [Desenvolvedora](#desenvolvedora)
+2. [Tecnologias utilizadas](#1-tecnologias-utilizadas)
+3. [Configuração para rodar o projeto](#2-configuração-para-rodar-o-projeto)
+4. [Repositórios Jest e Playwright](#3-por-que-existem-repositórios-com-playwright-e-jest)
+5. [Outras documentações](#4-outras-documentações)
+6. [Versionamento, code review e padronização](#5-versionamento-code-review-e-padronização-git)
+7. [Agradecimentos](#agradecimentos)
+
+---
+
+## Desenvolvedora
+
+<table>
+  <tr>
+    <td align="center"><a href="https://github.com/AlineEspindola"><img src="https://avatars.githubusercontent.com/AlineEspindola" width="80px;" alt="Aline Espindola"/><br /><sub><b>Aline Espindola</b></sub></a><br /><a href="#" title="Code">💻🎨</a></td>
+  </tr>
+</table>
+
+---
+
+## 1. Tecnologias utilizadas
+
+![TypeScript](https://img.shields.io/badge/TypeScript-3178C6?style=for-the-badge&logo=typescript&logoColor=white)  
+![Playwright](https://img.shields.io/badge/Playwright-2EAD33?style=for-the-badge&logo=playwright&logoColor=white)  
+![Node.js](https://img.shields.io/badge/Node.js-339933?style=for-the-badge&logo=node.js&logoColor=white)  
+![dotenv](https://img.shields.io/badge/dotenv-ECD53F?style=for-the-badge&logo=.env&logoColor=black)  
+![AJV](https://img.shields.io/badge/AJV-22B573?style=for-the-badge&logo=json&logoColor=white)  
+![Chance.js](https://img.shields.io/badge/Chance.js-FF69B4?style=for-the-badge&logo=javascript&logoColor=white)
+
+---
+
+## 2. Configuração para rodar o projeto
+
+> Antes de iniciar, **certifique-se de ter o Node instalado**.  
+
+1. Clonar o repositório:  
+```bash
+git clone https://github.com/tagplus-qa-lab/qa-junior-playwright-api.git
+cd qa-junior-playwright-api
+```
+
+2. Copiar o arquivo de exemplo de variáveis de ambiente:  
+```bash
+cp .env.example .env
+```
+> Esse 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.
+
+3. Criar token no seu **.env**. Você gera a partir do site do [GoRest](https://gorest.co.in)
+```bash
+GOREST_TOKEN=Seu Token
+```
+
+4. Instalar as dependências do projeto:  
+```bash
+npm i
+```
+
+5. Instalar os navegadores necessários do Playwright:  
+```bash
+npx playwright install
+```
+
+6. Executar todos os testes:  
+```bash
+npm test
+```
+---
+
+## 3. Por que existem repositórios com Playwright e Jest?
+
+Embora 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.
+
+### 💡 Multi-habilidade em ferramentas
+
+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.
+
+---
+
+## 4. Outras Documentações
+
+No projeto, algumas documentações adicionais estão disponíveis para referência e melhor organização dos testes e funcionalidades.  
+
+### Testes de Integração
+
+- Toda a documentação referente aos **testes automatizados de integração** está localizada na pasta `/docs`.
+
+---
+
+## 5. Versionamento, Code Review e Padronização Git
+
+- Controle de versão: Git + GitHub  
+- Versão inicial: 1.0.0  
+  - Todos requisitos cumpridos e documentados
+- 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.
+
+### Padrões de Desenvolvimento
+
+#### 📂 Estrutura de Branches
+
+Adotei o seguinte padrão:
+
+- **playwright-api-[id-da-tarefa]/**
+
+### ✅ Commits Semânticos
+
+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`            |
+
+---
+
+## Agradecimentos
+
+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.
+
+
+
+

docs/INTEGRATION_Test_Cases.md

@@ -0,0 +1,238 @@
+# Documentação de Testes de Integração - GoRest API
+
+## Índice
+1. [Users](#users)
+2. [Posts](#posts)
+3. [Comments](#comments)
+
+---
+
+## Users
+
+### TC-USER-001: GET /users deve retornar uma lista de usuários
+**Objetivo:** Validar que a API retorna corretamente a lista de usuários e que cada usuário está conforme o schema.  
+
+**Pré-condição:**  
+- Ter acesso à API GoRest.  
+
+**Passos:**  
+1. Enviar requisição GET para `/users`.  
+2. Validar o status da resposta (`200`).  
+3. Validar se o retorno é uma lista (`Array`).  
+4. Validar cada usuário utilizando o schema `userSchema`.  
+
+**Resultado esperado:**  
+- Retorno com status `200`.  
+- Lista de usuários válida de acordo com o schema.
+
+---
+
+### TC-USER-002: POST /users deve criar um usuário
+**Objetivo:** Validar que a API consegue criar um usuário com os dados fornecidos.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+
+**Passos:**  
+1. Enviar requisição POST para `/users` com dados válidos de um usuário.  
+2. Validar status da resposta (`201`).  
+3. Validar se o usuário retornado corresponde aos dados enviados.  
+4. Validar o usuário criado pelo schema `userSchema`.  
+
+**Resultado esperado:**  
+- Usuário criado com sucesso.  
+- Status da resposta `201`.  
+- Usuário retornado válido de acordo com o schema.
+
+---
+
+### TC-USER-003: PUT /users/:id deve atualizar um usuário
+**Objetivo:** Validar que a API consegue atualizar os dados de um usuário existente.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um usuário existente (pegar `id` aleatório).  
+
+**Passos:**  
+1. Enviar requisição PUT para `/users/:id` com novos dados.  
+2. Validar status da resposta (`200`).  
+3. Validar se os dados retornados correspondem aos novos dados enviados.  
+4. Validar usuário atualizado com `userSchema`.  
+
+**Resultado esperado:**  
+- Usuário atualizado com sucesso.  
+- Status da resposta `200`.  
+- Dados validados pelo schema.
+
+---
+
+### TC-USER-004: DELETE /users/:id deve deletar um usuário
+**Objetivo:** Validar que a API consegue deletar um usuário existente.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um usuário existente (pegar `id` aleatório).  
+
+**Passos:**  
+1. Enviar requisição DELETE para `/users/:id`.  
+2. Validar status da resposta (`204`).  
+
+**Resultado esperado:**  
+- Usuário deletado com sucesso.  
+- Status da resposta `204`.  
+
+---
+
+## Posts
+
+### TC-POST-001: GET /posts deve retornar uma lista de posts
+**Objetivo:** Validar que a API retorna corretamente a lista de posts e que cada post está conforme o schema.  
+
+**Pré-condição:**  
+- Ter acesso à API GoRest.  
+
+**Passos:**  
+1. Enviar requisição GET para `/posts`.  
+2. Validar status da resposta (`200`).  
+3. Validar se o retorno é uma lista (`Array`).  
+4. Validar cada post pelo schema `postSchema`.  
+
+**Resultado esperado:**  
+- Lista de posts retornada com sucesso.  
+- Status da resposta `200`.  
+- Posts válidos de acordo com o schema.
+
+---
+
+### TC-POST-002: POST /posts deve criar um post
+**Objetivo:** Validar que a API consegue criar um post com os dados fornecidos.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um usuário existente (`user_id`).  
+
+**Passos:**  
+1. Enviar requisição POST para `/posts` com dados válidos.  
+2. Validar status da resposta (`201`).  
+3. Validar se o post retornado corresponde aos dados enviados.  
+4. Validar post criado pelo schema `postSchema`.  
+
+**Resultado esperado:**  
+- Post criado com sucesso.  
+- Status da resposta `201`.  
+- Dados do post válidos de acordo com o schema.
+
+---
+
+### TC-POST-003: PUT /posts/:id deve atualizar um post
+**Objetivo:** Validar que a API consegue atualizar um post existente.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um post existente (pegar `id` aleatório).  
+
+**Passos:**  
+1. Enviar requisição PUT para `/posts/:id` com novos dados.  
+2. Validar status da resposta (`200`).  
+3. Validar se os dados retornados correspondem aos dados enviados.  
+4. Validar post atualizado pelo schema `postSchema`.  
+
+**Resultado esperado:**  
+- Post atualizado com sucesso.  
+- Status da resposta `200`.  
+- Dados validados pelo schema.
+
+---
+
+### TC-POST-004: DELETE /posts/:id deve deletar um post
+**Objetivo:** Validar que a API consegue deletar um post existente.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um post existente (pegar `id` aleatório).  
+
+**Passos:**  
+1. Enviar requisição DELETE para `/posts/:id`.  
+2. Validar status da resposta (`204`).  
+
+**Resultado esperado:**  
+- Post deletado com sucesso.  
+- Status da resposta `204`.
+
+---
+
+## Comments
+
+### TC-COMMENT-001: GET /comments deve retornar uma lista de comentários
+**Objetivo:** Validar que a API retorna corretamente a lista de comentários e que cada comentário está conforme o schema.  
+
+**Pré-condição:**  
+- Ter acesso à API GoRest.  
+
+**Passos:**  
+1. Enviar requisição GET para `/comments`.  
+2. Validar status da resposta (`200`).  
+3. Validar se o retorno é uma lista (`Array`).  
+4. Validar cada comentário pelo schema `commentSchema`.  
+
+**Resultado esperado:**  
+- Lista de comentários retornada com sucesso.  
+- Status da resposta `200`.  
+- Comentários válidos de acordo com o schema.
+
+---
+
+### TC-POST-002: POST /comments deve criar um comentário
+**Objetivo:** Validar que a API consegue criar um comentário com os dados fornecidos.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um post existente (`post_id`).  
+
+**Passos:**  
+1. Enviar requisição POST para `/comments` com dados válidos.  
+2. Validar status da resposta (`201`).  
+3. Validar se o comentário retornado corresponde aos dados enviados.  
+4. Validar comentário criado pelo schema `commentSchema`.  
+
+**Resultado esperado:**  
+- Comentário criado com sucesso.  
+- Status da resposta `201`.  
+- Dados válidos de acordo com o schema.
+
+---
+
+### TC-COMMENT-003: PUT /comments/:id deve atualizar um comentário
+**Objetivo:** Validar que a API consegue atualizar um comentário existente.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um comentário existente (pegar `id` aleatório).  
+
+**Passos:**  
+1. Enviar requisição PUT para `/comments/:id` com novos dados.  
+2. Validar status da resposta (`200`).  
+3. Validar se os dados retornados correspondem aos dados enviados.  
+4. Validar comentário atualizado pelo schema `commentSchema`.  
+
+**Resultado esperado:**  
+- Comentário atualizado com sucesso.  
+- Status da resposta `200`.  
+- Dados validados pelo schema.
+
+---
+
+### TC-COMMENT-004: DELETE /comments/:id deve deletar um comentário
+**Objetivo:** Validar que a API consegue deletar um comentário existente.  
+
+**Pré-condição:**  
+- Ter token válido de autenticação.  
+- Ter um comentário existente (pegar `id` aleatório).  
+
+**Passos:**  
+1. Enviar requisição DELETE para `/comments/:id`.  
+2. Validar status da resposta (`204`).  
+
+**Resultado esperado:**  
+- Comentário deletado com sucesso.  
+- Status da resposta `204`.