テスト完了（B2C）

実装開始前に、ご利用の環境に適用されるすべてのテストを完了してください。

品質保証は、重大な影響を受ける前に問題を特定するために重要です。プロジェクトの性質に応じて、異なる種類の品質保証テストから適したものを選び、Auth0統合の一環として実施することをご検討ください。

• アプリケーションは、障がいのある人にとっても理解しやすく、使いやすいですか。

• アプリケーションは、多種のブラウザーやデバイスで動作する必要がありますか。

• アプリケーションは、複数の国で、あるいは国際的な環境で動作する必要がありますか。

• 予期しない生産負荷が発生した場合、アプリケーションのパフォーマンスはどうなりますか。

• セキュリティー関連の脆弱性からアプリケーションをどのように保護しますか。

Auth0のユニバーサルログインおよび関連するUIウィジェット（Lockなど）は、使いやすさとアクセシビリティのベスト プラクティスに従ってすでに設計および構築されており、多くのブラウザーやデバイスに対してそのまますぐに使えるテスト済みのサポートを提供しています。国際化（I18N）のサポートも初めから組み込まれており、カスタムの多言語・ローカリゼーション（L10N）シナリオに対応できる拡張性を備えています。

機能的な要件が満たされ、予期しないイベントが正しく処理されるように、アプリケーションとAuth0の間の統合をテストするためのガイダンスと、個々の拡張モジュール（Rules、Hooks、カスタム データベースのスクリプトなど）のユニットテストに関するガイダンスが提供されます。また、セキュリティの脆弱性をテストする際に役立つAuth0のペネトレーションテストポリシーに関するガイダンスも提供されます。さらに、負荷テストポリシーと組み合わせてモックテストを活用して、予期しない負荷の下でもアプリケーションが確実に動作するための情報も提供されます。

ユニットテストの目的は、コードの個々のユニットをテストすることです。Auth0内でRules、Hooks、カスタムDBスクリプトの形式でカスタムコードを作成する場合は、テストフレームワーク（Mochaなど）を使用してコードをテストすることを検討してください。Auth0を上手に活用している企業は、Auth0テナントの構成その他を自動的にデプロイする前にユニットテストを行うと効果的だと言います。

ベストプラクティスとして、開発・テスト・運用用に個別のテナントをセットアップすることをお勧めします（「SDLCサポートのアーキテクチャガイダンス」を参照）。Auth0を使用すると、カスタム拡張性内から使用できる変数を構成できます。これらは、Auth0テナントの環境変数とみなすことができます。ハードコード化された参照は、開発・テスト・運用環境間で移動すると変わってしまうため、代わりに、テナントで構成され、カスタムの拡張コードによって参照される変数名を使用することができます。コードが変数を参照すれば、実行時にテナント固有の値が書き込まれるため、同じカスタムコードを異なるテナントで変更せずに使用できます。

• Rulesでの変数の使用については、値の構成方法

• Hooksでの変数の使用については、エディターでシークレットの構成方法を参照してください

• Actionsでの変数の使用については、「フローとトリガーを見る」

• カスタムDBスクリプトでの変数の使用については、構成パラメーター

デプロイメントの自動化とテストの自動化を組み込めば、ビルドプロセス全体を自動化できます。これを利用して、新しいバージョンの構成やカスタムコードをAuth0に導入し、自動テストを実行することができます。テストでエラーが見つかった場合は、デプロイメントの自動化機能を使用して、動作していた最後のバージョンに戻すことができます。詳細については、提供されている「デプロイメントの自動化に関するガイダンス」を参照してください。

Auth0の負荷テストポリシーと負荷テストを行いたいという要望とのバランスを取るため、Auth0のエンドポイントをモックすることが慣行となっています。これは、テストを制約することなく、想定したインターフェイスでのアプリケーションの動作を確認できる有効な方法であり、補助としてMockServer、JSON Server、Postmanといったツールを使用できます。

ペネトレーションテストを実行する場合は、Auth0のペネトレーションポリシーに留意し、それに従ってください。ペネトレーションテストを実行する際は、テストが悪意あるアクティビティと混同され、シャットダウンを引き起こさないように、Auth0への事前通知が必要です。

負荷テストを実行する場合は、Auth0の負荷テストポリシーに留意し、それに従ってください。負荷テストではAuth0への事前通知が必要です。負荷テストを計画する際は、Auth0のAPIレート制限にも注意を払う必要があります。

負荷テストはAuth0負荷テストポリシーで説明されている通り、Auth0からの事前承認が必要です。リクエストをしてからレビューにかかる時間に留意して、レビューとテスト実行のための時間を十分に確保するようにしてください。負荷テストのリクエストが承認されたら、エラーや不完全なテスト結果を回避するため、以下のガイダンスを参考にしてください。

• 実際の運用時に発生するすべての事項がテストされるよう、ご使用のアプリケーションのテスト時にHTTPトレースを実行して、アプリケーションまたは意図されたテストが行う必要のあるすべての呼び出しを特定します。

• テストを設計する際はAPIレート制限に留意します。

• Auth0のカスタムコード（Actions、Rules、 Hooks、カスタムデータベースのスクリプト、カスタムOAuth接続）を使うと、Auth0カスタムサンドボックスが呼び出されて性能が落ちる可能性があります。テストに不可欠でない限り、Rulesはオフにしてください。Rulesがオフだと、オンにされている場合に比べてスループットが改善します。

• 現実的なテスト結果をられるよう、運用環境で予想される全体の負荷と各エンドポイントへの呼び出し比率を推定し、それに基づいてパフォーマンステストを構成します。エンドポイントが異なればパフォーマンスコストも異なります。実際の環境を代表するテストを設計しないと、誤解を生じる結果になりかねません。

• 前提条件となっている呼び出しや応答が完了したことを確認せずに、以前の呼び出し結果に依存する呼び出しを行わないようにします。遅延させるだけでは十分でない場合があります。

• 必ず適切なエラー処理を実行します。テスト時に頻繁に発生する問題は、カスタムコード（Actions、Rules、 Hooks、カスタムデータベースのスクリプト、カスタムOAuth接続スクリプト）の例外処理が行われないことに起因するカスタムコードエラーです。

• 負荷テストは、最初低レベルで開始し、徐々にレベルを上げて各レベルでデータをキャプチャし、最も有益な結果が得られるように書いてください。高いレベルで開始してすぐに機能が停止しても、システムがどれだけ耐えられるかについての情報はそれほど得られません。

• 通常、パフォーマンステストでは、テスト中のコードやテストハーネス/構成を調節しながら複数回実行する必要があります。早めにテストを開始して、複数回反復できる時間を確保してください。

• ご自身のメールプロバイダーアカウントを使い、メールプロバイダーからレート制限を受けることのないよう、事前に十分なメール送信容量があることを確認します。使用しないのであれば、メール送信をオフにします。

• すべてのソーシャル接続では、Auth0の開発者キーでなく、必ずご自身のアカウント資格情報を使ってください。Auth0 dashboardで［Connections（接続）］> ［Social（ソーシャル）］ > {接続名}に移動して、その接続にご自身のソーシャルプロバイダ―アカウント資格情報を追加する手順を確認します。注意：ソーシャルプロバイダーによっては、負荷テストが許可されない場合もあります。お使いのプロバイダーのポリシーをご確認ください。

• レート制限を回避し、より正確に実際の負荷をシミュレートするため、同一ユーザーに全要求を送信するのでなく、複数ユーザーに送信する必要があります。一人または数人のみのユーザーを使うと、キャッシュによって実質的なロードが低下し、現実的な結果が得られない場合があります。

• テストで合意されたパラメーターと、Auth0負荷テストポリシーに必ず従ってください。Auth0は、パフォーマンステストや負荷テストが合意されたパラメーターまたは予定されたテストウィンドウを超えた場合、それらのテストを終了する権利を留保します。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。