test: unit tests for users module

[mathd1as]

Nesta PR foram implementadas as seguintes funcionalidades:

1. implementacao de testes unitarios para users serivce e users controller;
2. adicao de configuracao para executar o jest com o module alias;

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.

[vanflux]

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.

[mathd1as]

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.

[iagxferreira]

Achei muito boa a sugestão de configuração e uma ótima good-first-issue, se for aprovada eu irei propagar esse modelo de testes pra outras funcionalidades.

LGTM!

[vanflux]

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?
#159 (comment)
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"

[mathd1as]

@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]

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

[mathd1as]

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.