No vídeo, o professor acaba pegando o token real e setando na mão no teste. Isso não ocorreria numa aplicação real. A minha dúvida seria como essa parte de setar um token e pegar as informações do usuário seria feita
No vídeo, o professor acaba pegando o token real e setando na mão no teste. Isso não ocorreria numa aplicação real. A minha dúvida seria como essa parte de setar um token e pegar as informações do usuário seria feita
hoje, com a Alura e o Google Gemini
Fala ai Everton, tudo bem? Quando a gente está realizando testes unitários de forma isolada, o token é setado na mão mesmo (de N maneiras).
Isso porque para você obter o token da API ai já seria um teste end-to-end (e2e).
Não tem problema de setar na mão, isso porque a gente não está interessado em testar o token nesse momento e sim outras camadas da aplicação.
Espero ter ajudado.
Ok, mas então toda vez que o token expirar teria que setar na mão novamente? Isso rodando num pipeline do jenkins, por exemplo, não seria meio inviável/ruim?
Fala Everton, nesse caso você está criando um teste instável, que hora funciona e hora pode não funcionar.
O primeiro passo é tornar esse teste estável, garantir que ele vai sempre funcionar desde que os requisitos e asserções atendam o esperado.
No seu caso eu não sei o que está sendo testado, se for o serviço, você precisa testar a lógica que o mesmo está executando e não o token, pois, o token estar válido ou não já foi testado pela API.
Espero ter ajudado.
Como está especificado na referência, trata-se de um vídeo referente a um teste de serviço, onde há um método que seta um token para a obtenção de dados do usuário. O professor loga na aplicação, pega um token real, e adiciona no método de setar token, o que eu vejo que não seria feito no mundo real.
Fala Everton, nesse caso você precisa testar a funcionalidade em si, ou seja, no caso do TokenService você vai testar se o localStorage.setItem foi chamado, vai testar se o localStorage.getItem foi chamado e coisas do tipo.
No caso do UserService a ideia é mais ou menos a mesma, você vai testar a função de decodificar o token, vai testar se ela chamou as funções do TokenService.
A regra de testar se o token é válido ou inválido não estaria nesses testes unitários para esses serviços, mas, sim em um teste de integração (e2e) no serviço de autenticação.
Espero ter ajudado.
Olha, ainda não ficou claro... Então, pelo que está dizendo, vc está insinuando que o professor fez um teste que não deveria ter feito... Sendo que minha dúvida seria, dentro dos métodos de serviço, como seria testar o método que retorna dados do usuário a partir do token, onde o professor usou um token real, o que não ocorreria no mundo real...
Fala Everton, vamos lá, talvez eu tenha explicado da melhor forma.
Existem N tipos de testes que podemos fazer em uma aplicação front, exemplos:
Se você quer testar o token em si, você precisa realizar um teste e2e, ou seja, você vai de fato bater no back pegar um token e coisas do tipo.
Você não precisa deixar um token salvo no front, pois, com o tempo ele será inválido, nesse caso você pode buscar um novo token antes de executar o seu teste que precisa.
Caso você queira fazer um teste unitário, ai sim, você mocka o token, ou seja, deixa um token fixo e realiza os testes que façam sentidos de forma mockada, basicamente testes que não tornem o mesmo instável, exemplo: Decodificar, salvar no Local Storage, remover do Local Storage, Conteúdo, etc...
Resumindo, cada teste vai exigir uma abordagem e maneira diferente.
Desculpas pela confusão e má explicação da minha parte.
Agora fez sentido? Caso não tenha feito, vamos nos falando.
Espero ter ajudado.