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: alteração na documentação
• US<id>: 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