Learn-json-web-tokens: API de teste que usa JWTs

Bem, tenho algumas sugestões que podem funcionar:

1. Configure um cliente de _teste_ em seu sistema e codifique um token nos testes. Mantenha a autenticação ativada.
2. Certifique-se de que a autenticação esteja desligada ao executar os testes. Acho que existem diferentes maneiras de fazer isso. Por exemplo, no Hapi você pode deixar de fora o esquema de autenticação padrão e apenas definir um, quando o servidor realmente for executado (mas não ao executar testes).
3. Zombe da pilha, então você está apenas testando a lógica do controlador, sem fazer solicitações por meio do sistema. No entanto, pode não ser viável em alguns frameworks.

Estou trabalhando em alguns sistemas, onde escolhemos (1). Os testes então se parecem um pouco mais com os testes de integração e não com os testes de unidade, porque são executados na pilha. Por outro lado, não há disparidade entre o ambiente de teste e de produção.

Você pode definir NODE_ENV=test , ao executar os testes (parâmetro fx. -e no laboratório ), se quiser determinar o ambiente no código. No entanto, você deve estar ciente de que o ambiente de teste e produção não difere muito, caso contrário, você não está realmente testando o ambiente de produção.

@ rhewitt22 preferimos a abordagem descrita por @walling
(onde os testes se assemelham mais a testes de "integração" em vez de testes de "unidade")
por _precisamente_ esse motivo. Tudo que você zomba é "_fake_" e, portanto, você não saberá quando algo "_real_" funciona ou não (_então os bugs são mais prováveis_).

Nós herdamos (_large_) projetos onde as pessoas _esquecem_ de atualizar os mocks quando mudam os métodos e, como resultado, os testes não refletem a _realidade_; _ pesadelo para depurar _!

Sempre se pergunte: "_ ( Por que ) precisamos zombar disso ? _"

Se você está zombando de algo porque está fora de seu controle, por exemplo, um serviço de terceiros ou dispositivo de rede,
faz sentido. Mas se você está zombando de sua _a pilha _, você deve considerar que pode estar complicando demais as coisas ...

A dica em sua _question_ está no termo " _API _", isso indica que você não está testando uma "unidade", mas sim um (API) "_ endpoint _".

Acerte o endpoint e se você obtiver um 401 você sabe que precisa _autenticar_! (_Boas notícias! Seu aplicativo funciona conforme o esperado! _)

Aqui está um _exemplo de trabalho _ de um teste que faz _ exatamente o que você precisa _:
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

Então eu recomendaria a leitura:

• Quando zombar: https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• Mocks não são stubs: http://martinfowler.com/articles/mocksArentStubs.html
• Teste de microsserviços: http://martinfowler.com/articles/microservice-testing/
• Quando devo zombar? http://stackoverflow.com/questions/38181/when-should-i-mock

tl; dr

Se seu código _own_ for muito complexo e você sentir que _precisa_ simular, _primeiro simplifique seu código _ !!

Além disso, escrevemos nosso plug - in para que outros possam confiar em nossos testes. E lançou um exemplo _linear escalável_ apoiado pelo Redis: https://github.com/dwyl/hapi-auth-jwt2-example para que as pessoas possam copiar e colar (_testado_) o código! :piscar:

_Nós_ apenas zombamos quando nossos testes "_sentem ser muito lentos _", caso contrário, _sempre_ exercitamos tanto da pilha quanto _possível_ em cada passagem de teste (enquanto limitamos as dependências a apenas _essencial_).

Se um elemento da funcionalidade do seu aplicativo requer autenticação, por que você não usa isso como uma _oportunidade_ para _exercitar_ seus métodos de autenticação / verificação? No final das contas, saber quão _performant_ sua autenticação é _bom_ para seu aplicativo porque auth / verify é um dos maiores gargalos em sua pilha! (ou seja, _every_ GET / POST / PUT / DELETE _request_ tem que passar por auth / verify, então não deve demorar mais do que alguns milissegundos ... mais do que isso e seu aplicativo _não escalonará_!)

Lembre - nada _ e decida como faz sentido testar seu aplicativo. Se houvesse uma "maneira certa" de fazer os testes, todas as universidades estariam ensinando ... não há. A "melhor maneira" é a abordagem "_pragmática_"; faça o que fizer sentido para _seu_ projeto.

Espero que ajude. se não, por favor, deixe-nos saber onde você está travado! : +1:

Obrigado a ambos! Isso é incrivelmente útil. Com base na sua sugestão, acho que esta configuração se presta a testes de integração - definitivamente quero saber se essas peças estão funcionando juntas.

Estou usando apenas oAuth como meu método de autenticação (sem nome de usuário / senha). Estou interessado em aprender mais sobre como criar um cliente de teste. Eu sei que não quero passar por todo o fluxo oAuth, mas como você sugeriu hardcode um token que posso usar em meus testes. Você poderia recomendar algum recurso que possa me ajudar a entender como criar um cliente de teste?

Se ajudar, meu projeto atual usa SailsJS v11.0. Eu tenho um arquivo de teste de bootstrap que inicia meu servidor e cria / preenche um banco de dados na memória com acessórios. Pode ser um local apropriado para criar um cliente de teste?

Obrigado novamente - é maravilhoso encontrar pessoas tão dispostas a compartilhar seus conhecimentos.

@ rhewitt22 , bem, no meu caso, o cliente de teste foi tão simples quanto criar um token JWT não expirável assinado com a carga útil e a chave secreta corretas. Talvez isso ajude.

Em OAuth, acho que depende do fluxo de autenticação. Talvez você possa até criar o token de acesso final com certas permissões e que não expire, para que você não precise passar pelo fluxo todas as vezes.

Cuidado com as preocupações de segurança sobre a codificação permanente de um token que não expira em seus testes, se esse token também conceder muitas permissões no sistema de produção. Então, um invasor potencial precisaria apenas desse token para obter acesso. Você pode querer alguma forma de conceder acesso a certos clientes e, ao executar os testes, pode conceder acesso ao seu cliente de teste ou token. Espero que tudo faça sentido.

@walling

Obrigado pelo conselho!

Eu simplesmente fui em frente e criei um usuário falso, pulando o fluxo oAuth, em meus testes e concedi a eles o mesmo JWT (com expiração) que uso na produção. Todos os meus testes estão passando e eu sou um campista muito feliz.

: smile:: smile:: smile:

Percebi que, enquanto estou trabalhando em meu aplicativo e olhando para o servidor de desenvolvimento, estarei garantindo que a parte oAuth funcione conforme o esperado.