Learn-json-web-tokens: JWTを使用するAPIのテスト

さて、私はうまくいくかもしれないいくつかの提案があります：

1. システムに_test_クライアントをセットアップし、テストでトークンをハードコーディングします。 認証をオンのままにします。
2. テストを実行するときは、認証がオフになっていることを確認してください。 それを行うにはさまざまな方法があると思います。 たとえば、 Hapiでは、デフォルトの認証スキームを省略して、サーバーが実際に実行されているときに1つだけ設定できます（ただし、テストの実行時には設定できません）。
3. スタックをモックアウトするので、システムを介して要求を行うことなく、コントローラーロジックを単体テストするだけです。 ただし、一部のフレームワークでは実行できない場合があります。

私はいくつかのシステムに取り組んでおり、そこでは（1）を選択しました。 テストはスタックを介して実行されるため、単体テストではなく統合テストに少し似ています。 一方、テスト環境と本番環境の間に違いはありません。

コードで環境を判別する場合は、テストの実行時にNODE_ENV=testを設定できます（ラボではfx。 -eパラメーター）。 ただし、テスト環境と本番環境の違いはそれほど大きくないことに注意してください。違いがない場合は、実際に本番環境をテストしているわけではありません。

@ rhewitt22 @ wallingで説明されているアプローチをお勧めします
（テストが「単体」テストではなく「統合」に似ている場合）
_正確に_その理由で。 モックするものはすべて「_fake_」であるため、「_ real_」が機能するかどうかはわかりません（_バグが発生する可能性が高くなります_）。

私たちは、人々がメソッドを変更したときにモックを更新することを_忘れる_という（_large_）プロジェクトを継承しており、その結果、テストは_reality_を反映していません。 _デバッグの悪夢_！

常に自問してください：「_（なぜ）これをする必要があるのですか？_」

サードパーティのサービスやネットワークデバイスなど、制御できないために何かをモックしている場合は、
それは理にかなっている。 しかし、_自分のスタック_を物事を複雑にしすぎている可能性があると考えてください...

_question_の手がかりは、「_ API _」という用語にあります。これは、「ユニット」ではなく、（API）「_ endpoint_ 」をテストしていることを示しています。

エンドポイントに到達し、401を取得した場合は、_認証_する必要があることがわかります。 （_良いニュース！あなたのアプリは期待通りに動作します！_）

これが_あなたが必要としていることを正確に_行うテストの_実用的な例_です：
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

それなら私は読むことをお勧めします：

• モックするタイミング： https ：
• モックはスタブではありません： http ：
• マイクロサービスのテスト： http ：//martinfowler.com/articles/microservice-testing/
• いつモックする必要がありますか？ http://stackoverflow.com/questions/38181/when-should-i-mock

tl; dr

_own_コードが複雑すぎて、それをモックする必要があると感じた場合は、_最初にコードを単純化してください_ !!

また、他の人が私たちのテストに頼れるように、 hapi-auth-jwt2プラグインを作成しました。 そして、_linearscalable_Redisに裏打ちされた例をリリースしました： https ：

_We_は、テストが「_遅すぎる_」の場合にのみモックします。それ以外の場合は、各テストパスで_可能な限り_スタックを_常に_実行します（依存関係を_essential_のみに制限します）。

アプリの機能の要素に認証が必要な場合は、それを認証/検証メソッドを_実行する_機会_として使用してみませんか？ 最終的に、認証/検証はスタックの最大のボトルネックの1つであるため、認証がどの程度_パフォーマンス_であるかを知ることは、アプリにとって_良い_でしょう。 （つまり、_every_ GET / POST / PUT / DELETE_request_はauth / verifyを実行する必要があるため、数ミリ秒以上かかることはありません...それ以上で、アプリは_スケーリングされません_！）

覚えておいてください：_何も想定しないで_、アプリケーションをテストすることがどのように意味があるかについて自分で決めてください。 テストを行う「正しい方法」があれば、すべての大学がそれを教えているでしょう...ありません。 「最善の方法」は「_pragmatic_」アプローチです。 _your_プロジェクトにとって意味のあることをしてください。

お役に立てば幸いです。 そうでない場合は、行き詰まっている場所をお知らせください。 ：+1：

あなたがた両方に感謝します！ これは非常に役立ちます。 あなたの提案に基づいて、このセットアップは統合テストに役立つと思います-これらの部分が一緒に機能しているかどうかを絶対に知りたいです。

認証方法としてoAuthのみを使用しています（ユーザー名/パスワードは使用していません）。 テストクライアントの作成方法についてもっと知りたいです。 oAuthフロー全体を確認したくないことはわかっていますが、あなたが提案したように、テストで使用できるトークンをハードコーディングします。 テストクライアントの作成に頭を悩ませるのに役立つリソースをお勧めしますか？

それが私の現在のプロジェクトでSailsJSv11.0を使用するのに役立つ場合。 サーバーを起動し、メモリ内データベースにフィクスチャを作成/入力するブートストラップテストファイルがあります。 テストクライアントを作成するのに適切な場所でしょうか？

もう一度ありがとうございます。知識を共有してくれる人を見つけるのは素晴らしいことです。

@ rhewitt22 、まあ、私の場合、テストクライアントは、正しいペイロードと秘密鍵で署名された

OAuthでは、認証フローに依存すると思います。 たぶん、特定のアクセス許可を使用して最終アクセストークンを作成することもできますが、それは期限切れにならないため、毎回フローを実行する必要はありません。

有効期限が切れていないトークンを本番システムでも多くの権限を付与する場合は、そのトークンをテストでハードコーディングすることに関するセキュリティ上の懸念に注意してください。 その場合、潜在的な攻撃者はアクセスを取得するためにこのトークンのみを必要とします。 特定のクライアントへのアクセスを許可する方法が必要な場合があります。テストを実行するときに、テストクライアントまたはトークンへのアクセスを許可できます。 私はそれがすべて理にかなっていることを願っています。

@walling

アドバイスありがとうございます！

テストでは、oAuthフローをスキップして偽のユーザーを作成し、本番環境で使用するのと同じJWT（有効期限付き）を付与しました。 私のテストはすべて合格で、とても幸せなキャンピングカーです。

：smile ：： smile ：： smile：

アプリで作業していて開発サーバーを見ていると、oAuth部分が期待どおりに機能することを確認できると思います。