Skip to content

Commit 7bf20aa

Browse files
authored
[Pav-114] criar documentacao desenvolvimento local e padronização de testes (#213)
# Documentação de desenvolvimento local e padrão de testes automatizados ## Objetivo Criar uma documentação para facilitar o onboarding de novos contribuidores no projeto, centralizando informações sobre execução local da aplicação e o padrão utilizado para criação de testes automatizados. ## O que foi alterado Foi criada uma documentação contendo: ### Desenvolvimento local - Pré-requisitos necessários para executar o projeto. - Configuração inicial do ambiente. - Instalação das dependências. - Configuração das variáveis de ambiente. - Comandos utilizados para executar os serviços localmente. - Orientações para execução e validação da aplicação. ### Padrão de testes automatizados Foi documentado o padrão utilizado no projeto para organização de testes utilizando: - TP (Test Plan) - TC (Test Case) A documentação explica: - Diferença entre TP e TC. - Como estruturar cenários de teste. - Como criar novos casos de teste. - Boas práticas para testes unitários. - Quando utilizar `it.each`. - A importância de validar comportamento e regras do sistema, evitando testes acoplados a detalhes de implementação. ## Exemplo utilizado Foi utilizado como referência o fluxo de testes do Go Scraper:
2 parents 8370993 + 47116b3 commit 7bf20aa

12 files changed

Lines changed: 1264 additions & 135 deletions

‎GUIA_TESTES_AUTOMATIZADOS.md‎

Lines changed: 337 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,337 @@
1+
# Guia de Testes Automatizados
2+
3+
Este documento foi criado para quem nunca trabalhou com testes automatizados.
4+
5+
Se voce esta contribuindo pela primeira vez no projeto, começe por aqui.
6+
7+
## O que e um teste automatizado?
8+
9+
Um teste automatizado e um pequeno programa que verifica se uma funcionalidade continua funcionando como esperado.
10+
11+
Em vez de testar tudo manualmente toda vez, o teste automatizado executa cenarios e confirma o resultado por voce.
12+
13+
## Por que escrevemos testes?
14+
15+
Escrevemos testes para:
16+
17+
- evitar quebrar funcionalidades antigas
18+
- dar seguranca para melhorar o codigo
19+
- documentar como o sistema deve se comportar
20+
- facilitar revisao de Pull Request
21+
- ajudar novos contribuidores a entender o projeto
22+
23+
## O que acontece quando um teste falha?
24+
25+
Quando um teste falha, isso e um alerta.
26+
27+
Pode significar:
28+
29+
- bug novo
30+
- comportamento mudou sem querer
31+
- regra esperada deixou de ser atendida
32+
33+
Em geral, um teste falhando e uma protecao do projeto, nao um incomodo.
34+
35+
## Como testes ajudam novos desenvolvedores
36+
37+
Testes funcionam como documentacao viva.
38+
39+
Ao ler um teste, voce entende:
40+
41+
- qual entrada foi usada
42+
- qual comportamento era esperado
43+
- o que nao pode regredir
44+
45+
---
46+
47+
## Conceitos basicos
48+
49+
### O que e um cenario de teste?
50+
51+
Cenario de teste e uma situacao real do sistema.
52+
53+
Exemplo simples:
54+
55+
"Quando faco login com senha correta, espero entrar no sistema."
56+
57+
Isso vira:
58+
59+
- Cenario: usuario informa senha correta
60+
- Resultado esperado: sistema permite acesso
61+
62+
---
63+
64+
## O que e um TC (Test Case)
65+
66+
TC significa Test Case (Caso de Teste).
67+
68+
Um TC responde:
69+
70+
"Qual comportamento do sistema estou garantindo?"
71+
72+
Importante:
73+
74+
- TC nao e uma linha de codigo isolada
75+
- TC e um comportamento relevante
76+
77+
Exemplo real do projeto:
78+
79+
- backend/tests/unit/adapters/goScrapper/goScraper.TC01.ts
80+
81+
Responsabilidade desse TC:
82+
83+
- garantir que o adapter retorna vagas quando o Go Scraper responde com dados validos
84+
85+
---
86+
87+
## O que e um TP (Test Plan)
88+
89+
TP significa Test Plan (Plano de Testes).
90+
91+
TP e um documento/arquivo que organiza:
92+
93+
- o que sera testado
94+
- quais cenarios existem
95+
- quais TCs pertencem ao plano
96+
- resultados esperados
97+
98+
Exemplo real do projeto:
99+
100+
- backend/tests/unit/adapters/TP-01.goScraper.test.ts
101+
102+
Esse arquivo representa o planejamento dos testes do adapter Go Scraper.
103+
104+
Ele define:
105+
106+
- qual funcionalidade sera validada
107+
- qual o objetivo dos testes
108+
- quais cenarios precisam ser protegidos
109+
- quais TCs fazem parte desse plano
110+
111+
Antes de escrever codigo de teste, o primeiro passo e entender quais comportamentos precisam ser garantidos.
112+
113+
---
114+
115+
## Relacao entre TP e TC
116+
117+
O projeto utiliza esta relacao:
118+
119+
TP (Test Plan)
120+
->
121+
TC (Test Case)
122+
->
123+
Teste automatizado executavel
124+
125+
Explicando de forma simples:
126+
127+
- TP: planeja os cenarios
128+
- TC: implementa cada cenario
129+
- Suite de testes: executa tudo e valida o comportamento
130+
131+
### Estrutura de relacionamento (Go Scraper)
132+
133+
```text
134+
Go Scraper Adapter
135+
136+
TP-01.goScraper.test.ts
137+
138+
Define os cenarios:
139+
140+
|- TC-01
141+
| |- Resposta valida
142+
|
143+
|- TC-02
144+
| |- Erro HTTP
145+
|
146+
|- TC-03
147+
| |- Contrato invalido
148+
|
149+
|- TC-04
150+
| |- Parametros invalidos
151+
|
152+
|- TC-05
153+
| |- Envio de parametros
154+
|
155+
|- TC-06
156+
| |- Variavel de ambiente
157+
```
158+
159+
---
160+
161+
## Explicacao dos TCs reais do projeto
162+
163+
Arquivos reais atualmente:
164+
165+
- backend/tests/unit/adapters/goScrapper/goScraper.TC01.ts
166+
- backend/tests/unit/adapters/goScrapper/goScraper.TC02.ts
167+
- backend/tests/unit/adapters/goScrapper/goScraper.TC03.ts
168+
- backend/tests/unit/adapters/goScrapper/goScraper.TC04.ts
169+
- backend/tests/unit/adapters/goScrapper/goScraper.TC05.ts
170+
- backend/tests/unit/adapters/goScrapper/goScraper.TC06.ts
171+
172+
Resumo de cada cenario:
173+
174+
- TC01
175+
- Cenario: resposta valida do Go Scraper
176+
- Esperado: adapter retorna vagas corretamente
177+
178+
- TC02
179+
- Cenario: servico externo retorna erro HTTP
180+
- Esperado: adapter trata e propaga erro corretamente
181+
182+
- TC03
183+
- Cenario: resposta nao segue contrato esperado
184+
- Esperado: sistema rejeita resposta invalida
185+
186+
- TC04
187+
- Cenario: parametros invalidos de entrada
188+
- Esperado: falha antes de chamar servico externo
189+
190+
- TC05
191+
- Cenario: envio de parametros para o servico
192+
- Esperado: payload preserva dados esperados
193+
194+
- TC06
195+
- Cenario: URL do Go Scraper via variavel de ambiente
196+
- Esperado: adapter usa GO_SCRAPER_URL configurada
197+
198+
---
199+
200+
## Primeiro exemplo do projeto (passo a passo)
201+
202+
Use como referencia:
203+
204+
- backend/tests/unit/adapters/goScrapper/goScraper.TC01.ts
205+
206+
Passo a passo do que ele faz:
207+
208+
1. prepara uma resposta simulada (mock) da API externa
209+
2. executa o adapter
210+
3. verifica os dados retornados
211+
4. confirma que o comportamento esperado aconteceu
212+
213+
---
214+
215+
## Regra de qualidade dos testes
216+
217+
Teste unitario nao deve validar apenas uma linha ou chamada isolada.
218+
219+
Exemplo ruim:
220+
221+
```ts
222+
it("deve chamar funcao", () => {
223+
expect(mock.execute).toHaveBeenCalled();
224+
});
225+
```
226+
227+
Por que e ruim:
228+
229+
- valida detalhe interno
230+
- nao prova comportamento real
231+
232+
Exemplo melhor:
233+
234+
```ts
235+
it("deve retornar vagas quando a resposta do Go Scraper for valida", async () => {
236+
// cenario completo
237+
});
238+
```
239+
240+
Pergunta que todo bom teste deve responder:
241+
242+
"Qual comportamento do sistema estou garantindo?"
243+
244+
---
245+
246+
## Quando usar varios testes e quando usar it.each
247+
248+
Use TCs separados quando os cenarios sao diferentes.
249+
250+
Exemplo:
251+
252+
- resposta valida
253+
- erro HTTP
254+
- contrato invalido
255+
256+
Use `it.each` quando a regra e a mesma e so os dados mudam.
257+
258+
Exemplo:
259+
260+
```ts
261+
it.each([
262+
{ keyword: "Java" },
263+
{ keyword: "Node.js" },
264+
])( "deve buscar vagas corretamente", async ({ keyword }) => {
265+
// mesma regra, dados diferentes
266+
});
267+
```
268+
269+
Isso evita copiar e colar testes quase iguais.
270+
271+
---
272+
273+
## Processo para criar novos testes
274+
275+
1. Identificar a funcionalidade
276+
2. Criar ou atualizar o TP
277+
3. Definir cenarios
278+
4. Criar TCs necessarios
279+
5. Implementar os testes
280+
6. Executar testes localmente
281+
7. Abrir Pull Request
282+
283+
Comando util para backend:
284+
285+
```bash
286+
npm run test --workspace=backend
287+
```
288+
289+
---
290+
291+
## Beneficios desse padrao
292+
293+
Para iniciantes:
294+
295+
- facilita entender o projeto
296+
- funciona como documentacao viva
297+
- ajuda na primeira contribuicao
298+
299+
Para o projeto:
300+
301+
- melhora manutencao
302+
- facilita revisao de PR
303+
- reduz regressao
304+
- mantem qualidade com crescimento da comunidade
305+
306+
---
307+
308+
## Checklist para novos contribuidores
309+
310+
Antes de abrir PR, confirme:
311+
312+
- Existe um TP documentando o objetivo?
313+
- O TC representa um comportamento real?
314+
- O nome do teste esta claro?
315+
- Evitei testar detalhes internos?
316+
- Usei it.each quando os cenarios sao equivalentes?
317+
318+
---
319+
320+
## Nota de consistencia sobre nomes dos arquivos
321+
322+
Este guia usa os caminhos reais encontrados no repositorio no momento da escrita.
323+
324+
No prompt de referencia, alguns nomes aparecem como:
325+
326+
- TC-01.goScraper.test.ts
327+
- TP-01.goScraper.test.ts (como documento)
328+
329+
No codigo atual, os arquivos de TC estao nomeados como:
330+
331+
- goScraper.TC01.ts ate goScraper.TC06.ts
332+
333+
Isso nao muda o conceito.
334+
335+
O importante e manter a relacao:
336+
337+
TP planeja -> TC implementa -> teste automatizado protege comportamento.

0 commit comments

Comments
 (0)