Learn-json-web-tokens: Test-API, die JWTs verwendet

Nun, ich habe einige Vorschläge, die funktionieren könnten:

1. Richten Sie einen _test_-Client in Ihrem System ein und codieren Sie ein Token in den Tests hart. Lassen Sie die Authentifizierung eingeschaltet.
2. Stellen Sie sicher, dass die Authentifizierung deaktiviert ist, wenn Sie die Tests ausführen. Ich denke, es gibt verschiedene Möglichkeiten, dies zu tun. In Hapi können Sie beispielsweise das Standard-Authentifizierungsschema weglassen und nur eines festlegen, wenn der Server tatsächlich läuft (aber nicht beim Ausführen von Tests).
3. Mock-out des Stack, so dass Sie nur die Controller-Logik testen, ohne Anfragen über das System zu stellen. In einigen Frameworks ist dies jedoch möglicherweise nicht machbar.

Ich arbeite an einigen Systemen, bei denen wir (1) gewählt haben. Die Tests sehen dann eher wie Integrationstests und nicht wie Unit-Tests aus, da sie durch den Stack laufen. Andererseits besteht kein Unterschied zwischen Test- und Produktionsumgebung.

Sie können NODE_ENV=test festlegen, wenn Sie die Tests ausführen (zB Parameter -e in lab ), wenn Sie die Umgebung im Code bestimmen möchten. Sie sollten sich jedoch bewusst sein, dass sich Test- und Produktionsumgebung nicht allzu sehr unterscheiden, da Sie sonst die Produktionsumgebung nicht wirklich testen.

@rhewitt22 wir bevorzugen den von @walling beschriebenen Ansatz
(wo Tests eher "Integration" anstelle von "Unit"-Tests ähneln)
aus _genau_ diesem Grund. Alles, was Sie verspotten, ist "_fake_" und daher wissen Sie nicht, wann etwas "_real_" funktioniert oder nicht (_also sind Fehler wahrscheinlicher_).

Wir haben (_große_) Projekte geerbt, bei denen Leute _vergessen_, die Scheine zu aktualisieren, wenn sie Methoden ändern und als Ergebnis die Tests nicht die _Realität_ widerspiegeln; _ Albtraum zu debuggen _!

Sich immer fragen: „_ (Warum) brauchen wir dies verspotten _?“

Wenn Sie sich über etwas lustig machen, weil es außerhalb Ihrer Kontrolle liegt, z. B. ein Dienst von Drittanbietern oder ein Netzwerkgerät,
es ergibt Sinn. Aber wenn Sie Ihren _eigenen Stapel _ verspotten,

Der Hinweis in Ihrer _Frage_ liegt im Begriff " _API _", dies bedeutet, dass Sie keine "Einheit" testen, sondern einen (API) "_ Endpunkt _".

Erreichen Sie den Endpunkt und wenn Sie eine 401 erhalten, wissen Sie, dass Sie sich _authentifizieren_ müssen! (_Gute Neuigkeiten! Ihre App funktioniert wie erwartet!_)

Hier ist ein _Arbeitsbeispiel _ für einen Test, der _ genau das tut
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

Dann empfehle ich zu lesen:

• Wann sollte man sich lustig machen: https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• Mocks sind keine Stubs: http://martinfowler.com/articles/mocksArentStubs.html
• Microservice-Tests: http://martinfowler.com/articles/microservice-testing/
• Wann sollte ich spotten? http://stackoverflow.com/questions/38181/when-should-i-mock

tl;dr

Wenn Ihr _eigener_ Code zu komplex ist und Sie das _Bedürfnis_ haben, ihn zu verspotten, _vereinfachen Sie zuerst Ihren Code _!!

Außerdem haben wir unser hapi-auth-jwt2- Plugin geschrieben, damit sich andere auf unsere Tests verlassen können. Und veröffentlichte ein _linear skalierbares_ Redis-unterstütztes Beispiel: https://github.com/dwyl/hapi-auth-jwt2-example, damit Leute Code kopieren und einfügen (_tested_) können! :zwinkern:

_Wir_ verspotten nur, wenn sich unsere Tests "_zu langsam anfühlen_", ansonsten _immer_ wir _immer_ bei jedem Testdurchlauf so viel vom Stapel wie _möglich_ ausüben (während wir die Abhängigkeiten auf das _wesentliche_ beschränken).

Wenn ein Element Ihrer App-Funktionalität eine Authentifizierung erfordert, warum nutzen Sie dies nicht als _Gelegenheit_, um Ihre Authentifizierungs-/Verifizierungsmethoden _auszuüben_? Letztendlich ist es _gut_ für Ihre App zu wissen, wie _performant_ Ihre Authentifizierung ist, da Authentifizierung/Verifizierung einer der größten Engpässe in Ihrem Stack ist! (dh _jeder_ GET/POST/PUT/DELETE _request_ muss die Authentifizierung/Verifizierung durchlaufen, also sollte es nicht länger als ein paar Millisekunden dauern ... mehr als das und Ihre App _nicht skalieren_!)

Denken Sie etwas _ und bilden sich Ihre eigene Meinung darüber , wie es Sinn macht , Ihre Anwendung zu testen. Wenn es einen "richtigen Weg" gäbe, Tests durchzuführen, würden ihn alle Universitäten lehren ... gibt es nicht. Der "beste Weg" ist der "_pragmatic_"-Ansatz; tun, was für _Ihr_ Projekt sinnvoll ist.

Hoffentlich hilft das. wenn nicht, lass uns bitte wissen, wo du feststeckst! :+1:

Danke euch beiden! Das ist unglaublich hilfreich. Basierend auf Ihrem Vorschlag denke ich, dass sich dieses Setup für Integrationstests eignet - ich möchte auf jeden Fall wissen, ob diese Teile zusammenarbeiten.

Ich verwende nur oAuth als meine Authentifizierungsmethode (kein Benutzername/Passwort). Ich bin daran interessiert, mehr über das Erstellen eines Testclients zu erfahren. Ich weiß, dass ich nicht den gesamten oAuth-Flow durchlaufen möchte, aber wie Sie vorgeschlagen haben, muss ein Token hartcodiert werden, den ich in meinen Tests verwenden kann. Könnten Sie mir Ressourcen empfehlen, die mir helfen könnten, einen Testclient zu erstellen?

Wenn es hilft, verwendet mein aktuelles Projekt SailsJS v11.0. Ich habe eine Bootstrap-Testdatei , die meinen Server startet und eine In-Memory-Datenbank mit Fixtures erstellt/auffüllt. Könnte dies ein geeigneter Ort sein, um einen Testclient zu erstellen?

Nochmals vielen Dank – es ist wunderbar, Leute zu finden, die so bereit sind, ihr Wissen zu teilen.

@rhewitt22 , nun, in meinem Fall war der

Bei OAuth hängt es meiner Meinung nach vom Authentifizierungsablauf ab. Vielleicht können Sie sogar das endgültige Zugriffstoken mit bestimmten Berechtigungen erstellen, das nicht abläuft, sodass Sie nicht jedes Mal den Flow durchlaufen müssen.

Beachten Sie die Sicherheitsbedenken bezüglich der Hartcodierung eines nicht ablaufenden Tokens in Ihren Tests, wenn dieses Token auch viele Berechtigungen im Produktionssystem gewährt. Dann würde ein potenzieller Angreifer nur dieses Token benötigen, um Zugriff zu erhalten. Möglicherweise möchten Sie bestimmten Clients Zugriff gewähren, und beim Ausführen der Tests können Sie Ihrem Testclient oder Token Zugriff gewähren. Ich hoffe, es macht alles Sinn.

@walling

Danke für den Hinweis!

Ich habe einfach in meinen Tests einen gefälschten Benutzer erstellt, den oAuth-Flow übersprungen und ihnen dasselbe JWT (mit Ablauf) gewährt, das ich in der Produktion verwende. Alle meine Tests bestehen und ich bin ein sehr glücklicher Camper.

:Lächeln lächeln lächeln:

Ich denke, während ich an meiner App arbeite und mir den Entwicklungsserver anschaue, werde ich sicherstellen, dass der oAuth-Teil wie erwartet funktioniert.