> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > B2C IAM 実装のローンチに向けたテスト準備。 # テスト完了（B2C） ローンチ前に、環境に応じて必要なテストをすべて完了しておく必要があります。 品質保証は、お客様に影響が及ぶ前に問題を特定するうえで重要です。また、プロジェクトの性質によっては、Auth0 との統合の一環として検討すべき品質保証テストがいくつかあります。 * 障がいのある方を含め、誰にとってもアプリケーションは理解しやすく、使いやすいものになっていますか。 * アプリケーションは、さまざまなブラウザーやデバイスで動作する必要がありますか。 * アプリケーションは、多国籍環境や国際環境で動作する必要がありますか。 * 想定外の本番環境の負荷がかかった場合、アプリケーションはどのような動作をしますか。 * セキュリティ関連の脆弱性から、アプリケーションをどのように保護しますか。 Auth0 の [Universal Login](/ja/docs/authenticate/login/auth0-universal-login) と関連する UI ウィジェット ([Lock](/ja/docs/libraries/lock) など) は、すでにユーザビリティとアクセシビリティのベストプラクティスに従って設計・構築されており、幅広い [ブラウザーとデバイス](/ja/docs/troubleshoot/customer-support/product-support-matrix) に対して、テスト済みのすぐに利用できるサポートを提供しています。[国際化](/ja/docs/customize/internationalization-and-localization) (I18N) も標準でサポートされており、カスタムの多言語化やローカライズ (L10N) の要件に対応するための組み込みの拡張機能も備えています。 機能要件が満たされ、想定外の事象が正しく処理されることを確認するために、アプリケーションと Auth0 間の [統合](#integration-testing) テスト、および個々の拡張機能モジュール ([Rules](/ja/docs/customize/rules/debug-rules)、[Hooks](/ja/docs/customize/hooks/update-hooks)、Custom Database スクリプトなど) の [単体テスト](#unit-testing) に関するガイダンスが提供されています。また、セキュリティ脆弱性のテスト時に役立つ Auth0 の [ペネトレーションテストポリシー](/ja/docs/troubleshoot/customer-support/operational-policies/penetration-testing-policy) に関するガイダンスに加え、想定外の負荷がかかった場合でもアプリケーションが適切に動作するよう、[負荷テストポリシー](/ja/docs/troubleshoot/customer-support/operational-policies/load-testing-policy) とあわせて [モック](#mock-testing) テストをどのように活用できるかについても案内しています。
## 単体テスト
単体テストの目的は、コードの個々の単位を検証することです。Auth0 で Rules、Hooks、または Custom DB スクリプトとしてカスタムコードを作成する場合は、コードのテストに [Mocha](https://mochajs.org/) などのテストフレームワークを使用することを検討してください。Auth0 を効果的に活用している企業では、Auth0 テナントの設定や関連資産を[自動的にデプロイ](/ja/docs/get-started/architecture-scenarios/business-to-consumer/deployment)する前に、これらの単体テストを実行することが有用であるとわかっています。
## 統合テスト
[SDLC support](/ja/docs/get-started/architecture-scenarios/business-to-consumer/architecture#sdlc-support) のアーキテクチャガイダンスで説明しているように、開発、テスト、本番用にそれぞれ別のテナントを設定することを推奨します。Auth0 では、カスタム [拡張機能](/ja/docs/customize/extensions) から利用できる変数を設定できます。これは Auth0 テナントの環境変数と考えることができます。開発、テスト、本番の各環境間でコードを移動するたびに変わる参照先をハードコードする代わりに、テナントで設定した変数名をカスタム拡張機能コードから参照できます。これにより、実行時にテナント固有の値が設定される変数を参照できるため、同じカスタムコードを変更せずに異なるテナントで利用しやすくなります。 * Rules での変数の使用については、[値の設定方法](/ja/docs/customize/rules/configuration) を参照してください * Hooks での変数の使用については、エディタで [シークレット](/ja/docs/customize/hooks/hook-secrets) を設定する方法を参照してください * Actions での変数の使用については、「Flows and Triggers」を参照してください * Custom DB Scripts での変数の使用については、[設定パラメーター](/ja/docs/authenticate/database-connections/custom-db/create-db-connection#step-3-add-configuration-parameters) を参照してください ### ベストプラクティス テナント固有の値や、カスタムコード内に公開すべきでない機密のシークレットは、変数に格納することを推奨します。カスタムコードを GitHub にデプロイしている場合、テナント固有の変数を使用することで、GitHub リポジトリを通じた機密値の漏えいを防ぐことができます。
### テスト自動化
デプロイ自動化に加えてテスト自動化を組み込むことで、ビルドプロセス全体を自動化できます。これにより、設定やカスタムコードの新しいバージョンをAuth0にデプロイし、自動テストを実行できます。テストで障害が見つかった場合は、デプロイ自動化機能を使用して、最後に正常に動作していたバージョンにロールバックできます。詳細については、[デプロイ自動化ガイダンス](/ja/docs/get-started/architecture-scenarios/business-to-consumer/deployment)を参照してください。
## モックテスト
Auth0 の [負荷テストポリシー](/ja/docs/troubleshoot/customer-support/operational-policies/load-testing-policy) を踏まえつつ負荷テストも行いたい場合、Auth0 のお客様の間では Auth0 のエンドポイントをモック化するのが一般的です。これは、テストを制限することなく、アプリケーションが想定したインターフェイスで動作することを確認するための有効な手法であり、[MockServer](http://www.mock-server.com/)、[JSON Server](https://github.com/typicode/json-server)、さらには [Postman](https://learning.getpostman.com/docs/postman/mock_servers/setting_up_mock/) などのツールを利用できます。
## ペネトレーションテスト (任意)
ペネトレーションテストを実施する場合は、Auth0 の[ペネトレーションテストポリシー](/ja/docs/troubleshoot/customer-support/operational-policies/penetration-testing-policy)を確認し、これに従ってください。テストが悪意のあるアクティビティと誤認されて停止されないよう、ペネトレーションテストを実施する際は事前に Auth0 へ通知する必要があります。
## 負荷テスト (任意)
負荷テストを実施する場合は、Auth0の[負荷テストポリシー](/ja/docs/troubleshoot/customer-support/operational-policies/load-testing-policy)を確認し、これに従ってください。負荷テストを行うには、事前にAuth0への通知が必要です。負荷テストを計画する際は、Auth0の[APIレート制限](/ja/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy)についても把握しておく必要があります。 負荷テストには、Auth0の負荷テストポリシーに記載されているとおり、Auth0による事前承認が必要です。リクエストの審査に必要なリードタイムを確認し、審査とテスト実施の両方に十分な時間を見込んでください。負荷テストのリクエストが承認された場合は、以下のガイダンスに従うことで、エラーや不正確なテスト結果を避けやすくなります。 * アプリケーションのテスト実行時にHTTPトレースを実行し、アプリケーションまたは予定しているテストで必要となるすべての呼び出しを特定してください。本番環境で実際に発生する処理を反映できるよう、それらの呼び出しがテストに含まれていることを確認してください。 * Auth0 APIのレート制限を考慮してテストを設計してください。 * Auth0内のカスタムコード (Actions、Rules、Hooks、カスタムデータベーススクリプト、カスタムOAuth接続) を使用すると、Auth0のカスタムコードサンドボックスが呼び出されるため、パフォーマンス面のオーバーヘッドが増える場合があります。Rulesは、テストに不可欠でない限り無効にしてください。無効にすると、有効時よりもスループットが高くなります。 * 本番環境で想定される全体的な負荷と、各エンドポイントへの呼び出し割合を見積もり、それに合わせてパフォーマンステストを構成してください。そうすることで、現実に近いテスト結果が得られます。エンドポイントごとにパフォーマンスコストは異なります。実態を反映したテストを設計しないと、誤解を招く結果になります。 * 先行する呼び出しの結果に依存する呼び出しは、前提となる呼び出しやレスポンスの完了を確認せずに実行しないでください。単に遅延を入れるだけでは不十分な場合があります。 * 十分なエラーハンドリングを必ず実装してください。テスト中の問題でよくある原因は、カスタムコード (Actions、Rules、Hooks、カスタムデータベーススクリプト、カスタムOAuth接続スクリプト) で未処理の例外が発生することによるエラーです。 * 負荷テストは、低いレベルから開始し、各レベルでデータを収集しながら段階的に負荷を増やすように作成してください。そのほうが、より有用な結果を得られます。高いレベルから開始してすぐに失敗すると、システムがどの程度の負荷に耐えられるかについて得られる情報は少なくなります。 * パフォーマンステストは、複数回実行し、必要に応じてテスト対象のコードやテストハーネス/構成を調整するのが一般的です。複数回の反復に十分な時間を確保できるよう、早めにテストを開始してください。 * 独自のメールプロバイダーアカウントを使用し、十分なメール送信クォータを事前に確保してください。そうしないと、メールプロバイダー側でレート制限される可能性があります。使用しない場合は、メール送信を無効にしてください。 * すべてのソーシャル接続で、Auth0 dev keysではなく、必ず独自のアカウント認証情報を使用してください。Auth0 Dashboardで、Connections -> Social -> \{name of connection} に移動すると、独自のソーシャルプロバイダーアカウント認証情報をその接続に追加する方法を確認できます。注: 一部のソーシャルプロバイダーでは負荷テストが許可されていません。各プロバイダーのポリシーを確認してください * レート制限を回避し、実際の負荷をより正確にシミュレートするには、同じユーザーに対するリクエストばかりではなく、異なるユーザーに対するリクエストを送信する必要があります。1人または少数のユーザーだけを使用すると、キャッシュによって実効負荷が下がり、現実的な結果が得られない可能性があります。 * テストについて合意されたパラメーターとAuth0の負荷テストポリシーの範囲内に必ず収めてください。Auth0は、合意されたパラメーターの範囲を逸脱する、または予定されたテスト時間枠を超えて実施されるパフォーマンス/負荷テストを停止する権利を留保します。
## プロジェクト計画ガイド
推奨戦略の詳細を確認できるよう、ダウンロードして参照できる PDF 形式の計画ガイドを提供しています。 [B2C IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)