| ... | ... | @@ -13,22 +13,46 @@ Esta seção contém todos a metodologia escolhida para realização dos testes |
|
|
|
- [Descrição](#descrição)
|
|
|
|
- [Sumário](#sumário)
|
|
|
|
- [Testes](#testes)
|
|
|
|
- [Passar teste](#passar-teste)
|
|
|
|
- [Falhar testes](#falhar-testes)
|
|
|
|
- [Padrão de tasks](#padrão-de-tasks)
|
|
|
|
- [Padronização de código](#padronizacao-de-codigo)
|
|
|
|
- [Fluxo gitlab](#fluxo-gitlab)
|
|
|
|
- [Merge](#merge)
|
|
|
|
|
|
|
|
## Testes
|
|
|
|
|
|
|
|
TBD
|
|
|
|
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
|
|
|
|
|
|
|
|
## Passar teste
|
|
|
|
## Padronização de código
|
|
|
|
|
|
|
|
TBD
|
|
|
|
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
|
|
|
|
|
|
|
|
## Falhar testes
|
|
|
|
## Fluxo gitlab
|
|
|
|
|
|
|
|
TBD
|
|
|
|
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:
|
|
|
|
|
|
|
|
## Padrão de tasks
|
|
|
|
1. Criar uma **nova** branch **a partir da develop** com o formato "[US00]TaskName", por exemplo:
|
|
|
|
|
|
|
|
TBD |
|
|
|
[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. |
