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