diff --git a/README.md b/README.md index 9097710..d87d5bb 100644 --- a/README.md +++ b/README.md @@ -1 +1,143 @@ -# qa-junior-playwright-api \ No newline at end of file +# 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 + + + + + +
Aline Espindola
Aline Espindola
💻🎨
+ +--- + +## 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. + + + + diff --git a/docs/INTEGRATION_Test_Cases.md b/docs/INTEGRATION_Test_Cases.md new file mode 100644 index 0000000..6abc961 --- /dev/null +++ b/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`. diff --git a/docs/gherkin/comment.feature b/docs/gherkin/comment.feature new file mode 100644 index 0000000..e69de29 diff --git a/docs/gherkin/post.feature b/docs/gherkin/post.feature new file mode 100644 index 0000000..57e698b --- /dev/null +++ b/docs/gherkin/post.feature @@ -0,0 +1,30 @@ +Feature: Posts + As a QA + I want to validate the Posts API endpoints + So that CRUD operations work as expected + + Scenario: TC-POST-001 GET /posts deve retornar uma lista de posts + Given que a API GoRest está disponível + When envio uma requisição GET para "/posts" + Then o status da resposta deve ser 200 + And a resposta deve ser uma lista de posts válida de acordo com o schema + + Scenario: TC-POST-002 POST /posts deve criar um post + Given que possuo um token válido e um usuário existente + When envio uma requisição POST para "/posts" com dados válidos + Then o status da resposta deve ser 201 + And o post criado deve corresponder aos dados enviados + And o post deve ser válido de acordo com o schema + + Scenario: TC-POST-003 PUT /posts/:id deve atualizar um post + Given que possuo um token válido e um post existente + When envio uma requisição PUT para "/posts/:id" com novos dados + Then o status da resposta deve ser 200 + And os dados do post retornado devem corresponder aos novos dados + And o post atualizado deve ser válido de acordo com o schema + + Scenario: TC-POST-004 DELETE /posts/:id deve deletar um post + Given que possuo um token válido e um post existente + When envio uma requisição DELETE para "/posts/:id" + Then o status da resposta deve ser 204 + And o post deve ser deletado com sucesso \ No newline at end of file diff --git a/docs/gherkin/user.feature b/docs/gherkin/user.feature new file mode 100644 index 0000000..814930a --- /dev/null +++ b/docs/gherkin/user.feature @@ -0,0 +1,30 @@ +Feature: Users + As a QA + I want to validate the Users API endpoints + So that CRUD operations work as expected + + Scenario: TC-USER-001 GET /users deve retornar uma lista de usuários + Given que a API GoRest está disponível + When envio uma requisição GET para "/users" + Then o status da resposta deve ser 200 + And a resposta deve ser uma lista de usuários válida de acordo com o schema + + Scenario: TC-USER-002 POST /users deve criar um usuário + Given que possuo um token válido de autenticação + When envio uma requisição POST para "/users" com dados válidos + Then o status da resposta deve ser 201 + And o usuário criado deve corresponder aos dados enviados + And o usuário deve ser válido de acordo com o schema + + Scenario: TC-USER-003 PUT /users/:id deve atualizar um usuário + Given que possuo um token válido e um usuário existente + When envio uma requisição PUT para "/users/:id" com novos dados + Then o status da resposta deve ser 200 + And os dados do usuário retornado devem corresponder aos novos dados + And o usuário atualizado deve ser válido de acordo com o schema + + Scenario: TC-USER-004 DELETE /users/:id deve deletar um usuário + Given que possuo um token válido e um usuário existente + When envio uma requisição DELETE para "/users/:id" + Then o status da resposta deve ser 204 + And o usuário deve ser deletado com sucesso \ No newline at end of file