qualidade

Home	Escopo e Cronograma	Processo	Design/Mockups	Configuração	Arquitetura	Código	BD	Qualidade	Utilização	Contratos

Controle de Qualidade

Descrição

Esta seção contém todos a metodologia escolhida para realização dos testes do projeto.

Sumário

Índice de qualidade
Testes
Padronização de código
Fluxo gitlab
Merge

Índice de qualidade

Nossas métricas para definir a qualidade do nosso código são, essencialmente, a execução de todos nossos testes unitários sem erros, em conjunto com a nossa verificação de sintaxe.

Foram utilizadas duas ferramentas principais para obter esses dados:

Jest: ferramenta de testes unitários
Eslint: ferramenta para análise sintática

Com essas duas ferramentas é possível eliminar variáveis não utilizadas, funções que alteraram incorretamente o funcionamento do código, uso inconsistente de aspas (simples vs duplas), entre diversos outros fatores que mantém o código limpo e organizado, assim como executando como esperado.

Testes

Todas features implementadas terão dois tipos de teste:

Teste unitário: feito pelo desenvolvedor que implementou a feature de forma isolada em funções.
Teste de integração: feito por um colega utilizando insomnia e simulando chamadas reais da API

Padronização de código

O projeto executa verificações de código com regras pré programadas sempre que forem submetidos novos códigos, essa verificação é feita em duas etapas:

Antes de enviar o código localmente
Após o código ter sido enviado no servidor do Gitlab

Fluxo gitlab

Sempre que for iniciado o desenvolvimento de uma nova task, alguns passos devem ser seguidos para que seja feito uso correto do git e facilite a realização do merge para enviar para produção, são eles:

Criar uma nova branch a partir da develop com o formato "US00-TaskName", por exemplo:
```
US24-CreateStudent
```
Enviar commits com a mensagem sempre no imperativo e de forma descritiva, exemplo:
```
 Adiciona nova rota cadastrar estudante
```
Nada de commits como:
```
  Corrige service
```
Essa mensagem diz que tu arrumou o service, mas o que estava quebrado? Um melhor exemplo seria:
```
  Corrige mensagem de erro retornada no getAll do userService
```
Criar o MR para a develop após terminar a implementação da feature, caso os testes estejam falhando ou a verificação de sintaxe não valide, o MR será recusado

Merge

Uma branch de código pode ser merged com a develop somente se tiver passado com sucesso nos testes e na validação de sintaxe.

Somente maintainers tem a capacidade de realizar merges na develop e na main.