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.

Sumário

• Padrões de commit
• Revisão de código
• Padrões de código
• Testes unitários

📚 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: adiciona uma nova funcionalidade ao projeto.
• fix: corrige um defeito ou erro existente no código.
• chore: aplica mudanças que não afetam diretamente o código-fonte da aplicação (como atualizações de dependências ou configurações).
• docs: modifica apenas a documentação do projeto.
• test: adiciona ou altera testes automatizados.
• refactor: realiza refatorações de código que não alteram o comportamento funcional do sistema.
• style: ajusta aspectos de formatação e estilo do código, sem impacto na lógica do programa.

Exemplo de commit válido:

feat/date-modal

Nomeação de branches

O projeto recomenda o uso de padrão de nomeação de branch fornecido pela ferremanta Linear. De acordo com a escrita adotada para as tasks, que inclui:

• Nome do desenvolvedor responsável
• Id da task
• Descrição da tarefa

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

🔍 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