Learn-json-web-tokens: API de test qui utilise des JWT

Eh bien, j'ai quelques suggestions qui pourraient fonctionner:

1. Configurez un client _test_ dans votre système et codez en dur un jeton dans les tests. Gardez l'authentification activée.
2. Assurez-vous que l'authentification est désactivée lors de l'exécution des tests. Je suppose qu'il y a différentes façons de le faire. Par exemple, dans Hapi, vous pouvez omettre le schéma d'authentification par défaut et n'en définir qu'un lorsque le serveur s'exécute réellement (mais pas lors de l'exécution de tests).
3. Simulez la pile, de sorte que vous ne testez que l'unité de la logique du contrôleur, sans faire de demandes via le système. Cependant, cela peut ne pas être faisable dans certains cadres.

Je travaille sur certains systèmes, où nous avons choisi (1). Les tests ressemblent alors un peu plus à des tests d'intégration et non à des tests unitaires, car ils parcourent la pile. En revanche, il n'y a pas de disparité entre l'environnement de test et de production.

Vous pouvez définir NODE_ENV=test , lors de l'exécution des tests (fx. paramètre -e dans lab ), si vous souhaitez déterminer l'environnement dans le code. Cependant, vous devez savoir que l'environnement de test et de production ne diffère pas trop, sinon vous ne testez pas vraiment l'environnement de production.

@rhewitt22 nous préférons l'approche décrite par @walling
(où les tests ressemblent plus à des tests « d'intégration » au lieu de « tests unitaires »)
pour _précisément_ cette raison. Tout ce dont vous vous moquez est "_fake_" et donc vous ne saurez pas quand quelque chose "_real_" fonctionne ou non (_donc les bugs sont plus probables_).

Nous avons hérité de (_larges_) projets où les gens _oublient_ de mettre à jour les simulacres lorsqu'ils changent de méthode et, par conséquent, les tests ne reflètent pas la _réalité_ ; _ cauchemar à déboguer _ !

Demandez-vous toujours: « _ (Pourquoi) avons-nous besoin de se moquer de

Si vous vous moquez de quelque chose parce qu'il est hors de votre contrôle, par exemple un service tiers ou un périphérique réseau,
Ca a du sens. Mais si vous vous moquez de votre

L'indice dans votre _question_ est dans le terme " _API _", cela indique que vous ne testez pas une "unité", mais plutôt un (API) "_ endpoint _".

Atteignez le point de terminaison et si vous obtenez un 401, vous savez que vous devez vous authentifier ! (_Bonne nouvelle ! Votre application fonctionne comme prévu !_)

Voici un _exemple fonctionnel _ d'un test qui fait _ exactement ce dont vous avez besoin _ :
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

Ensuite, je recommanderais de lire :

• Quand se moquer : https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• Les simulacres ne sont pas des talons : http://martinfowler.com/articles/mocksArentStubs.html
• Tests de microservices : http://martinfowler.com/articles/microservice-testing/
• Quand dois-je me moquer ? http://stackoverflow.com/questions/38181/when-should-i-mock

tl; dr

Si votre _propre_ code est trop complexe et que vous ressentez le _besoin_ de vous en moquer, _simplifiez d'abord votre code _ !!

De plus, nous avons écrit notre plugin hapi-auth-jwt2 afin que d'autres puissent se fier à nos tests. Et a publié un exemple soutenu par Redis _linear scalable_ : https://github.com/dwyl/hapi-auth-jwt2-example afin que les gens puissent copier-coller (_testé_) le code ! :clin d'œil:

_Nous_ ne nous moquons que lorsque nos tests "_se sentent trop lents_" sinon nous _toujours_ exercer autant de pile que _possible_ à chaque passage de test (tout en limitant les dépendances uniquement à l'_essentiel_).

Si un élément de la fonctionnalité de votre application nécessite une authentification, pourquoi ne l'utilisez-vous pas comme _opportunité_ d'_exercer_ vos méthodes d'authentification/vérification ? En fin de compte, savoir à quel point votre authentification est _performante_ sera _bon_ pour votre application, car auth/verify est l'un des plus gros goulots d'étranglement de votre pile ! (c'est-à-dire que _chaque_ GET/POST/PUT/DELETE_request_ doit passer par auth/verify donc cela ne devrait pas prendre plus de quelques millisecondes ... plus que cela et votre application _ne s'adaptera pas_ !)

N'oubliez pas : ne _supposez rien _ et décidez vous-même en quoi il est logique de tester votre application. S'il y avait une "bonne façon" de faire les tests, toutes les universités l'enseigneraient... il n'y en a pas. La "meilleure façon" est l'approche "_pragmatique_" ; faire ce qui a du sens pour _votre_ projet.

J'espère que cela pourra aider. sinon, dites-nous où vous êtes bloqué ! :+1:

Merci à vous deux! C'est incroyablement utile. Sur la base de votre suggestion, je pense que cette configuration se prête aux tests d'intégration - je veux vraiment savoir si ces éléments fonctionnent ensemble.

J'utilise uniquement oAuth comme méthode d'authentification (pas de nom d'utilisateur/mot de passe). Je souhaite en savoir plus sur la création d'un client de test. Je sais que je ne veux pas parcourir tout le flux oAuth, mais comme vous l'avez suggéré, codez en dur un jeton que je peux utiliser dans mes tests. Pourriez-vous me recommander des ressources qui pourraient m'aider à comprendre comment créer un client de test ?

Si cela peut aider, mon projet actuel utilise SailsJS v11.0. J'ai un fichier de test d'amorçage qui démarre mon serveur et crée/remplit une base de données en mémoire avec des appareils. Serait-ce un endroit approprié pour créer un client de test ?

Merci encore - c'est merveilleux de trouver des gens si désireux de partager leurs connaissances.

@rhewitt22 , eh bien, dans mon cas, le client de test était aussi simple que de créer un jeton JWT non expirant signé avec la charge utile et la clé secrète correctes. Peut-être que ça aide.

Dans OAuth, je pense que cela dépend du flux d'authentification. Peut-être que vous pouvez même créer le jeton d'accès final avec certaines autorisations et qui n'expire pas, vous n'avez donc pas à parcourir le flux à chaque fois.

Méfiez-vous des problèmes de sécurité liés au codage en dur d'un jeton non expirant dans vos tests, si ce jeton accorde également de nombreuses autorisations dans le système de production. Ensuite, un attaquant potentiel n'aurait besoin que de ce jeton pour y accéder. Vous souhaiterez peut-être un moyen d'accorder l'accès à certains clients, et lors de l'exécution des tests, vous pouvez accorder l'accès à votre client ou jeton de test. J'espère que tout a du sens.

@murage

Merci pour le conseil!

Je suis juste allé de l'avant et j'ai créé un faux utilisateur, en sautant le flux oAuth, dans mes tests et je leur ai accordé le même JWT (avec expiration) que j'utilise en production. Tous mes tests passent et je suis un campeur très heureux.

:sourire: :sourire: :sourire:

Je pense que pendant que je travaille sur mon application et que je regarde le serveur de développement, je m'assurerai que la partie oAuth fonctionne comme prévu.