This is an old version of this page. You can view the most recent version or browse the history.

qualidade

Home	Escopo	Arquitetura	Configuração	Mockups	BD	Gerência	Qualidade	Processo

Controle de Qualidade

Esta seção tem por objetivo detalhar as convenções de commit, os padrões de codificação, as diretrizes de code review e a metodologia empregada nos testes unitários do projeto.

📚 Padrões de commit

O projeto adota o padrão Conventional Commits, que define uma convenção para a escrita de mensagens de commit, com o objetivo de padronizar o histórico de alterações, tornando-o mais legível, organizado e automatizável.

Tipos de commit do padrão especificado

feat: Uma nova funcionalidade (feature)
fix: Uma correção de bug (bug fix)
chore: Tarefas de manutenção que não alteram o código-fonte visível ao usuário (ex: ajustes de build, configuração de CI/CD, gerenciamento de dependências)
docs: Alterações na documentação (ex: README.md, CONTRIBUTING.md)
style: Alterações que não afetam o significado do código (espaços em branco, formatação, ponto e vírgula, etc.). Geralmente relacionado ao Prettier/ESLint
refactor: Uma alteração no código que não corrige um bug nem adiciona uma funcionalidade (ex: renomear uma variável, melhorar a performance de um algoritmo)
test: Adicionando ou corrigindo testes
ci: Alterações em arquivos de configuração de Integração Contínua (ex: .gitlab-ci.yml)

Exemplo de commit válido:

feat/date-modal

Nomeação de branches

Cada nova funcionalidade, correção ou tarefa deve ser desenvolvida em uma branch própria, criada a partir da versão mais atual da branch developer. Para manter a organização e o rastreamento claros, o nome da branch deve possuir as seguintes informações:

tipo: indica a categoria da
- feat: novas funcionalidades
- fix: correção de bugs
- chore: tarefas de manutenção ou configurações que não impactam diretamente o código-fonte
- **docs:*8 alteração na documentação
USid: identificador da User Story (ou tarefa) no sistema de gerenciamento
nome-descritivo: breve descrição em inglês do objetivo da branch, utilizando palavras minúsculas separadas por hífens

Sendo assim um o modelo de padrão a ser seguindo seria:

tipo/US<id>-nome-descritivo

Exemplos de nomeação de branch válidos:

feat/US101-auth-module
fix/US125-producer-validation-error
chore/US130-update-dockerfile
docs/US132-update-readme-contribution-guide

🔍 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.

📏 Padrões de código

O projeto utiliza a ferramenta ESLint (https://eslint.org/) para identificar rapidamente erros, padrões inconsistentes ou más práticas no código. Seu principal objetivo é garantir a padronização do código, promovendo legibilidade, manutenibilidade e qualidade técnica em equipes de desenvolvimento.

Além disso, o projeto emprega o Prettier (https://prettier.io/) para padronizar o estilo visual do código, independentemente de quem o escreveu. O Prettier foca na formatação consistente, aumentando a legibilidade, a uniformidade e a agilidade no desenvolvimento.

A equipe adotou a convenção de usar nomes em inglês para variáveis, funções e classes, sempre em camelCase, garantindo clareza, consistência e facilidade de manutenção do código.

🧪 Testes unitários

Back-end

Os testes automatizados são parte essencial da garantia de qualidade do projeto. Eles asseguram que as funcionalidades do sistema se comportem conforme o esperado, mesmo após novas implementações ou refatorações. 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)
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.

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.

Testes End-to-End (E2E)

Os testes E2E verificam o fluxo completo da aplicação, simulando o uso real do sistema. Para isso, o Jest sobe uma instância da aplicação em memória e utiliza a biblioteca supertest para enviar requisições HTTP (como GET /areas ou POST /producers), validando o código de status e o corpo da resposta. Esses testes asseguram que todos os componentes do sistema — módulos, rotas e integrações — estejam funcionando em conjunto corretamente.

Execução

Os testes são executados com o comando:

npm test

Esse comando faz com que o Jest:

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