Controle de Qualidade

Descrição

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

Sumário

• Controle de Qualidade
  • Descrição
  • Sumário
  • Testes
  • Padronização de código
  • Fluxo gitlab
  • Merge

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:

1. Antes de enviar o código localmente
2. 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:

1. Criar uma nova branch a partir da develop com o formato "[US00]TaskName", por exemplo:

   [US24]CreateStudent

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

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