Open mathd1as opened 3 months ago
Top a config, mas faz sentido adicionar testes unitários nesse módulo? Não parece ter nenhuma regra de negócio que vale a pena ser testada, a controller só repassa a call diretamente pra service. Vai dificultar mudanças na controller quando e se tiver. Vale mais a pena fazer testes de integração, não vai mudar o teste a literal cada mini mudança nos métodos da controller.
Foi refatorado os testes unitarios da controller users.service.spec.ts
para testes de integracao. Onde verificamos se as respostas recebidas da controller sao as esperadas.
Foi refatorado os testes unitarios da controller
users.service.spec.ts
para testes de integracao. Onde verificamos se as respostas recebidas da controller sao as esperadas.
@mathd1as Poderia por favor dar uma olhadinha nesse comentário que fiz em outro PR? https://github.com/SOS-RS/backend/pull/159#issuecomment-2123373657 Ele se aplica aqui de certa forma, queria trazer essa reflexão pra ti, faz sentido fazermos esses testes unitários? Ou será que de integração chamando a api via http não faz mais sentido? O teste cumpriria o propósito ainda, mas não é só um check de "código de hoje == código antigo"
@vanflux boa entendi o ponto. Porem para realizar o teste de integracao da controller nestas rotas(users) e nescessario um token JWT com as informacoes de sessao e userId com a permissao de admin, para passar do guard AdminGuard e eu nao consegui encontrar estes dados no front-end. Se vcs conseguirem me fornecer estes dados, consigo refatorar os testes para que tenhamos o teste de integracao nos endpoints de users.
@vanflux boa entendi o ponto. Porem para realizar o teste de integracao da controller nestas rotas(users) e nescessario um token JWT com as informacoes de sessao e userId com a permissao de admin, para passar do guard AdminGuard e eu nao consegui encontrar estes dados no front-end. Se vcs conseguirem me fornecer estes dados, consigo refatorar os testes para que tenhamos o teste de integracao nos endpoints de users.
Acho que teria que ter uma seed pra desenvolvimento, esse teste teria que chamar a rota de login com os dados de teste e pegar o token pra chamar as outras rotas de admin.
O problema de ter uma seed para desenvolvimento e que nos estariamos condicionando este teste ao ambiente nao? E o problema disso e que o mesmo teste pode falhar em producao se nao for o mesmo banco utilizado nos ambientes. E neste cenario pela complexidade do teste de integracao acredito que faz sentido nos mantermos os testes unitarios da controller para testarmos apenas os cenarios em que funcao retorna a resposta esperada isoladamente dos guards de autenticacao.
Os testes de integracao podemos tratar como teste e2e, visto que e nescessario ter toda estrutura de banco de dados rodando, e toda parte de login e autenticacao da rota. Desta forma acredito que estariamos dividindo melhor os testes em suas suites. Por mais que hoje nao temos tantas logicas de negocio na users.controller.ts
.
Nesta PR foram implementadas as seguintes funcionalidades:
Como executar
Executar todos os testes:
npm run test
Executar por arquivo:
npm run test <caminhoDoArquivo>/users.controller.spec.ts
npm run test <caminhoDoArquivo>/users.service.spec.ts
Resultado esperado: espera-se que todos os testes da suite de usuarios (users) tenham passado.
Os demais testes estao dando erro de configuracao/mock e ainda nao foram tratados.