Skip to content

Commit 0e1303e

Browse files
AlineEspindolaAlineEspindola
authored
Merge pull request #6 from tagplus-qa-lab/api-playwright-3/documentation
Api playwright 3/documentation
2 parents a3f7a64 + 3deb9ee commit 0e1303e

File tree

5 files changed

+441
-1
lines changed

5 files changed

+441
-1
lines changed

‎README.md‎

Lines changed: 143 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,143 @@
1-
# qa-junior-playwright-api
1+
# Documentação do Projeto de Testes Automatizados para GoRest
2+
3+
Índice
4+
1. [Desenvolvedora](#desenvolvedora)
5+
2. [Tecnologias utilizadas](#1-tecnologias-utilizadas)
6+
3. [Configuração para rodar o projeto](#2-configuração-para-rodar-o-projeto)
7+
4. [Repositórios Jest e Playwright](#3-por-que-existem-repositórios-com-playwright-e-jest)
8+
5. [Outras documentações](#4-outras-documentações)
9+
6. [Versionamento, code review e padronização](#5-versionamento-code-review-e-padronização-git)
10+
7. [Agradecimentos](#agradecimentos)
11+
12+
---
13+
14+
## Desenvolvedora
15+
16+
<table>
17+
<tr>
18+
<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>
19+
</tr>
20+
</table>
21+
22+
---
23+
24+
## 1. Tecnologias utilizadas
25+
26+
![TypeScript](https://img.shields.io/badge/TypeScript-3178C6?style=for-the-badge&logo=typescript&logoColor=white)
27+
![Playwright](https://img.shields.io/badge/Playwright-2EAD33?style=for-the-badge&logo=playwright&logoColor=white)
28+
![Node.js](https://img.shields.io/badge/Node.js-339933?style=for-the-badge&logo=node.js&logoColor=white)
29+
![dotenv](https://img.shields.io/badge/dotenv-ECD53F?style=for-the-badge&logo=.env&logoColor=black)
30+
![AJV](https://img.shields.io/badge/AJV-22B573?style=for-the-badge&logo=json&logoColor=white)
31+
![Chance.js](https://img.shields.io/badge/Chance.js-FF69B4?style=for-the-badge&logo=javascript&logoColor=white)
32+
33+
---
34+
35+
## 2. Configuração para rodar o projeto
36+
37+
> Antes de iniciar, **certifique-se de ter o Node instalado**.
38+
39+
1. Clonar o repositório:
40+
```bash
41+
git clone https://github.com/tagplus-qa-lab/qa-junior-playwright-api.git
42+
cd qa-junior-playwright-api
43+
```
44+
45+
2. Copiar o arquivo de exemplo de variáveis de ambiente:
46+
```bash
47+
cp .env.example .env
48+
```
49+
> Esse arquivo já vem configurado com o link padrão do site GoRest, utilizado nos testes automatizados.
50+
> 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.
51+
52+
3. Criar token no seu **.env**. Você gera a partir do site do [GoRest](https://gorest.co.in)
53+
```bash
54+
GOREST_TOKEN=Seu Token
55+
```
56+
57+
4. Instalar as dependências do projeto:
58+
```bash
59+
npm i
60+
```
61+
62+
5. Instalar os navegadores necessários do Playwright:
63+
```bash
64+
npx playwright install
65+
```
66+
67+
6. Executar todos os testes:
68+
```bash
69+
npm test
70+
```
71+
---
72+
73+
## 3. Por que existem repositórios com Playwright e Jest?
74+
75+
Embora este projeto tenha repositórios com **Playwright API** e **Jest API**, ambos são utilizados **apenas para testes de integração**.
76+
77+
- **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.
78+
79+
- **Jest**: é a ferramenta **preferida para testes de integração** neste projeto, pois oferece:
80+
- Execução **mais rápida** de testes de APIs e funções isoladas.
81+
- Manutenção mais prática, sem depender de navegador ou UI.
82+
83+
### 💡 Multi-habilidade em ferramentas
84+
85+
Ter repositórios com ambas as ferramentas demonstra **versatilidade** e conhecimento em diferentes stacks de teste.
86+
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.
87+
88+
---
89+
90+
## 4. Outras Documentações
91+
92+
No projeto, algumas documentações adicionais estão disponíveis para referência e melhor organização dos testes e funcionalidades.
93+
94+
### Testes de Integração
95+
96+
- Toda a documentação referente aos **testes automatizados de integração** está localizada na pasta `/docs`.
97+
98+
---
99+
100+
## 5. Versionamento, Code Review e Padronização Git
101+
102+
- Controle de versão: Git + GitHub
103+
- Versão inicial: 1.0.0
104+
- Todos requisitos cumpridos e documentados
105+
- 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.
106+
107+
### Padrões de Desenvolvimento
108+
109+
#### 📂 Estrutura de Branches
110+
111+
Adotei o seguinte padrão:
112+
113+
- **playwright-api-[id-da-tarefa]/**
114+
115+
### ✅ Commits Semânticos
116+
117+
Utilizei o padrão **Conventional Commits** para manter o histórico limpo e informativo:
118+
119+
📌 **Nota:** Escrevo os verbos no **imperativo**. Isso descreve o que o commit faz, como uma instrução ou comando, por exemplo: _"Adiciona", "Corrige", "Ajusta"_.
120+
121+
| Tipo | Descrição | Exemplo de Mensagem |
122+
| ---------- | ---------------------------------------------------- | ---------------------------------------------- |
123+
| `feat` | Adição de nova funcionalidade | `feat(playwright-api-12): adiciona mock do usuário` |
124+
| `fix` | Correção de bugs | `fix(playwright-api-14): corrige erro de exibição dos dados dos posts` |
125+
| `docs` | Atualização ou criação de documentação | `docs(playwright-api-12): atualiza README com padrões` |
126+
| `refactor` | Refatorações de código sem mudanças de comportamento | `refactor(playwright-api-12): simplifica lógica do utils` |
127+
| `test` | Adição ou atualização de testes | `test(playwright-api-13): adiciona testes para componente Header` |
128+
| `chore` | Atualizações gerais (ex.: dependências, build) | `chore(playwright-api-54): atualiza versão do Playwright` |
129+
| `perf` | Melhorias de performance | `perf(playwright-api-12): otimiza carregamento de dados` |
130+
| `revert` | Reversão de um commit anterior | `revert(playwright-api-11): remove validação do nome do usuário` |
131+
132+
---
133+
134+
## Agradecimentos
135+
136+
Gostaria de agradecer a **TagPlus** pela oportunidade de participar deste processo seletivo.
137+
Agradeço também a todos que irão avaliar o projeto, revisar código e fornecer feedbacks valiosos.
138+
139+
Foi uma experiência enriquecedora aplicar boas práticas de desenvolvimento e testes automatizados neste projeto.
140+
141+
142+
143+

‎docs/INTEGRATION_Test_Cases.md‎

Lines changed: 238 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,238 @@
1+
# Documentação de Testes de Integração - GoRest API
2+
3+
## Índice
4+
1. [Users](#users)
5+
2. [Posts](#posts)
6+
3. [Comments](#comments)
7+
8+
---
9+
10+
## Users
11+
12+
### TC-USER-001: GET /users deve retornar uma lista de usuários
13+
**Objetivo:** Validar que a API retorna corretamente a lista de usuários e que cada usuário está conforme o schema.
14+
15+
**Pré-condição:**
16+
- Ter acesso à API GoRest.
17+
18+
**Passos:**
19+
1. Enviar requisição GET para `/users`.
20+
2. Validar o status da resposta (`200`).
21+
3. Validar se o retorno é uma lista (`Array`).
22+
4. Validar cada usuário utilizando o schema `userSchema`.
23+
24+
**Resultado esperado:**
25+
- Retorno com status `200`.
26+
- Lista de usuários válida de acordo com o schema.
27+
28+
---
29+
30+
### TC-USER-002: POST /users deve criar um usuário
31+
**Objetivo:** Validar que a API consegue criar um usuário com os dados fornecidos.
32+
33+
**Pré-condição:**
34+
- Ter token válido de autenticação.
35+
36+
**Passos:**
37+
1. Enviar requisição POST para `/users` com dados válidos de um usuário.
38+
2. Validar status da resposta (`201`).
39+
3. Validar se o usuário retornado corresponde aos dados enviados.
40+
4. Validar o usuário criado pelo schema `userSchema`.
41+
42+
**Resultado esperado:**
43+
- Usuário criado com sucesso.
44+
- Status da resposta `201`.
45+
- Usuário retornado válido de acordo com o schema.
46+
47+
---
48+
49+
### TC-USER-003: PUT /users/:id deve atualizar um usuário
50+
**Objetivo:** Validar que a API consegue atualizar os dados de um usuário existente.
51+
52+
**Pré-condição:**
53+
- Ter token válido de autenticação.
54+
- Ter um usuário existente (pegar `id` aleatório).
55+
56+
**Passos:**
57+
1. Enviar requisição PUT para `/users/:id` com novos dados.
58+
2. Validar status da resposta (`200`).
59+
3. Validar se os dados retornados correspondem aos novos dados enviados.
60+
4. Validar usuário atualizado com `userSchema`.
61+
62+
**Resultado esperado:**
63+
- Usuário atualizado com sucesso.
64+
- Status da resposta `200`.
65+
- Dados validados pelo schema.
66+
67+
---
68+
69+
### TC-USER-004: DELETE /users/:id deve deletar um usuário
70+
**Objetivo:** Validar que a API consegue deletar um usuário existente.
71+
72+
**Pré-condição:**
73+
- Ter token válido de autenticação.
74+
- Ter um usuário existente (pegar `id` aleatório).
75+
76+
**Passos:**
77+
1. Enviar requisição DELETE para `/users/:id`.
78+
2. Validar status da resposta (`204`).
79+
80+
**Resultado esperado:**
81+
- Usuário deletado com sucesso.
82+
- Status da resposta `204`.
83+
84+
---
85+
86+
## Posts
87+
88+
### TC-POST-001: GET /posts deve retornar uma lista de posts
89+
**Objetivo:** Validar que a API retorna corretamente a lista de posts e que cada post está conforme o schema.
90+
91+
**Pré-condição:**
92+
- Ter acesso à API GoRest.
93+
94+
**Passos:**
95+
1. Enviar requisição GET para `/posts`.
96+
2. Validar status da resposta (`200`).
97+
3. Validar se o retorno é uma lista (`Array`).
98+
4. Validar cada post pelo schema `postSchema`.
99+
100+
**Resultado esperado:**
101+
- Lista de posts retornada com sucesso.
102+
- Status da resposta `200`.
103+
- Posts válidos de acordo com o schema.
104+
105+
---
106+
107+
### TC-POST-002: POST /posts deve criar um post
108+
**Objetivo:** Validar que a API consegue criar um post com os dados fornecidos.
109+
110+
**Pré-condição:**
111+
- Ter token válido de autenticação.
112+
- Ter um usuário existente (`user_id`).
113+
114+
**Passos:**
115+
1. Enviar requisição POST para `/posts` com dados válidos.
116+
2. Validar status da resposta (`201`).
117+
3. Validar se o post retornado corresponde aos dados enviados.
118+
4. Validar post criado pelo schema `postSchema`.
119+
120+
**Resultado esperado:**
121+
- Post criado com sucesso.
122+
- Status da resposta `201`.
123+
- Dados do post válidos de acordo com o schema.
124+
125+
---
126+
127+
### TC-POST-003: PUT /posts/:id deve atualizar um post
128+
**Objetivo:** Validar que a API consegue atualizar um post existente.
129+
130+
**Pré-condição:**
131+
- Ter token válido de autenticação.
132+
- Ter um post existente (pegar `id` aleatório).
133+
134+
**Passos:**
135+
1. Enviar requisição PUT para `/posts/:id` com novos dados.
136+
2. Validar status da resposta (`200`).
137+
3. Validar se os dados retornados correspondem aos dados enviados.
138+
4. Validar post atualizado pelo schema `postSchema`.
139+
140+
**Resultado esperado:**
141+
- Post atualizado com sucesso.
142+
- Status da resposta `200`.
143+
- Dados validados pelo schema.
144+
145+
---
146+
147+
### TC-POST-004: DELETE /posts/:id deve deletar um post
148+
**Objetivo:** Validar que a API consegue deletar um post existente.
149+
150+
**Pré-condição:**
151+
- Ter token válido de autenticação.
152+
- Ter um post existente (pegar `id` aleatório).
153+
154+
**Passos:**
155+
1. Enviar requisição DELETE para `/posts/:id`.
156+
2. Validar status da resposta (`204`).
157+
158+
**Resultado esperado:**
159+
- Post deletado com sucesso.
160+
- Status da resposta `204`.
161+
162+
---
163+
164+
## Comments
165+
166+
### TC-COMMENT-001: GET /comments deve retornar uma lista de comentários
167+
**Objetivo:** Validar que a API retorna corretamente a lista de comentários e que cada comentário está conforme o schema.
168+
169+
**Pré-condição:**
170+
- Ter acesso à API GoRest.
171+
172+
**Passos:**
173+
1. Enviar requisição GET para `/comments`.
174+
2. Validar status da resposta (`200`).
175+
3. Validar se o retorno é uma lista (`Array`).
176+
4. Validar cada comentário pelo schema `commentSchema`.
177+
178+
**Resultado esperado:**
179+
- Lista de comentários retornada com sucesso.
180+
- Status da resposta `200`.
181+
- Comentários válidos de acordo com o schema.
182+
183+
---
184+
185+
### TC-POST-002: POST /comments deve criar um comentário
186+
**Objetivo:** Validar que a API consegue criar um comentário com os dados fornecidos.
187+
188+
**Pré-condição:**
189+
- Ter token válido de autenticação.
190+
- Ter um post existente (`post_id`).
191+
192+
**Passos:**
193+
1. Enviar requisição POST para `/comments` com dados válidos.
194+
2. Validar status da resposta (`201`).
195+
3. Validar se o comentário retornado corresponde aos dados enviados.
196+
4. Validar comentário criado pelo schema `commentSchema`.
197+
198+
**Resultado esperado:**
199+
- Comentário criado com sucesso.
200+
- Status da resposta `201`.
201+
- Dados válidos de acordo com o schema.
202+
203+
---
204+
205+
### TC-COMMENT-003: PUT /comments/:id deve atualizar um comentário
206+
**Objetivo:** Validar que a API consegue atualizar um comentário existente.
207+
208+
**Pré-condição:**
209+
- Ter token válido de autenticação.
210+
- Ter um comentário existente (pegar `id` aleatório).
211+
212+
**Passos:**
213+
1. Enviar requisição PUT para `/comments/:id` com novos dados.
214+
2. Validar status da resposta (`200`).
215+
3. Validar se os dados retornados correspondem aos dados enviados.
216+
4. Validar comentário atualizado pelo schema `commentSchema`.
217+
218+
**Resultado esperado:**
219+
- Comentário atualizado com sucesso.
220+
- Status da resposta `200`.
221+
- Dados validados pelo schema.
222+
223+
---
224+
225+
### TC-COMMENT-004: DELETE /comments/:id deve deletar um comentário
226+
**Objetivo:** Validar que a API consegue deletar um comentário existente.
227+
228+
**Pré-condição:**
229+
- Ter token válido de autenticação.
230+
- Ter um comentário existente (pegar `id` aleatório).
231+
232+
**Passos:**
233+
1. Enviar requisição DELETE para `/comments/:id`.
234+
2. Validar status da resposta (`204`).
235+
236+
**Resultado esperado:**
237+
- Comentário deletado com sucesso.
238+
- Status da resposta `204`.

‎docs/gherkin/comment.feature‎

Whitespace-only changes.

0 commit comments

Comments
 (0)