| ... | ... | @@ -96,7 +96,7 @@ O projeto recomenda o uso de padrão de nomeação de branch fornecido pela ferr |
|
|
|
Também pode-se incluir o número da user story correspondente para a funcionalidade.
|
|
|
|
Sendo assim um exemplo de nome de branch de acordo com o padrão especificado seria:
|
|
|
|
|
|
|
|
**nomedesenvolvedor/ai-45-us05-date-modal**
|
|
|
|
`nomedesenvolvedor/ai-45-us05-date-modal`
|
|
|
|
|
|
|
|
## 🔍 Revisão de código
|
|
|
|
Todo código desenvolvido deve ser submetido a code review. Para que o merge request seja aprovado, ele precisa passar por uma análise, garantindo qualidade, consistência e conformidade com as diretrizes do projeto.
|
| ... | ... | @@ -114,24 +114,24 @@ Os testes automatizados são parte essencial da garantia de qualidade do projeto |
|
|
|
Para isso, o projeto utiliza o Jest, um framework de testes completo para JavaScript/TypeScript amplamente adotado no ecossistema NestJS.
|
|
|
|
O Jest atua como o executor e verificador dos testes. Ele oferece um ambiente integrado que combina:
|
|
|
|
|
|
|
|
- **Test Runner:** executa automaticamente todos os arquivos de teste do projeto (.spec.ts e .e2e-spec.ts)
|
|
|
|
- **Test Runner:** executa automaticamente todos os arquivos de teste do projeto (`.spec.ts` e `.e2e-spec.ts`)
|
|
|
|
- **Assertion Library:** permite escrever verificações claras com a função expect(), usada para comparar o resultado obtido com o resultado esperado
|
|
|
|
- **Mocking Library:** possibilita simular dependências externas, como repositórios ou serviços, isolando a lógica da unidade testada
|
|
|
|
- **Relatórios:** exibe no terminal um resumo dos testes, indicando quais passaram (PASS) e quais falharam (FAIL)
|
|
|
|
|
|
|
|
### Estrutura e convenções
|
|
|
|
Os arquivos de teste seguem um padrão para que o Jest os identifique automaticamente:
|
|
|
|
- *.spec.ts: testes unitários de uma funcionalidade específica, como areas.service.spec.ts
|
|
|
|
- *.e2e-spec.ts: testes ponta-a-ponta (End-to-End), que verificam o comportamento da aplicação completa através de requisições HTTP reais.
|
|
|
|
- `*.spec.ts`: testes unitários de uma funcionalidade específica, como areas.service.spec.ts
|
|
|
|
- `*.e2e-spec.ts`: testes ponta-a-ponta (End-to-End), que verificam o comportamento da aplicação completa através de requisições HTTP reais.
|
|
|
|
|
|
|
|
O sufixo _.spec_ vem de Specification, reforçando a ideia de que cada teste documenta o comportamento esperado do código, e não apenas o valida.
|
|
|
|
O sufixo `.spec` vem de Specification, reforçando a ideia de que cada teste documenta o comportamento esperado do código, e não apenas o valida.
|
|
|
|
|
|
|
|
|
|
|
|
### Tipos de teste
|
|
|
|
- Testes Unitários
|
|
|
|
|
|
|
|
Os testes unitários garantem que partes isoladas do sistema (como services e controllers) funcionem corretamente.
|
|
|
|
Usando o módulo de testes do NestJS (@nestjs/testing), é possível injetar dependências simuladas (mocks) e validar apenas a lógica da unidade sob teste, sem interação real com o banco de dados ou outros módulos.
|
|
|
|
Usando o módulo de testes do NestJS (`@nestjs/testing`), é possível injetar dependências simuladas (mocks) e validar apenas a lógica da unidade sob teste, sem interação real com o banco de dados ou outros módulos.
|
|
|
|
|
|
|
|
- Testes End-to-End (E2E)
|
|
|
|
|
| ... | ... | @@ -142,10 +142,10 @@ Esses testes asseguram que todos os componentes do sistema — módulos, rotas e |
|
|
|
### Execução
|
|
|
|
Os testes são executados com o comando:
|
|
|
|
|
|
|
|
**npm test**
|
|
|
|
`npm test`
|
|
|
|
|
|
|
|
Esse comando faz com que o Jest:
|
|
|
|
- Localize todos os arquivos *.spec.ts e *.e2e-spec.ts no projeto
|
|
|
|
- Localize todos os arquivos `*.spec.ts` e `*.e2e-spec.ts` no projeto
|
|
|
|
- Execute cada caso de teste de forma isolada
|
|
|
|
- Gere um relatório no terminal com os resultados, tempos de execução e possíveis erros
|
|
|
|
|
| ... | ... | |
