> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# B2B 品質保証

> カスタムコードの単体テスト、統合テスト、モックテストを通じて、問題がお客様に影響する前に検出できるよう、品質保証を Auth0 B2B 連携に組み込みます。

品質保証は、お客様に影響が及ぶ前に問題を特定するうえで重要です。また、プロジェクトの性質によっては、Auth0 との連携の一環として検討すべき品質保証テストがいくつかあります。

* 障害のある方を含め、アプリケーションは誰にとっても理解しやすく使いやすいものになっていますか？
* アプリケーションは、さまざまなブラウザーやデバイスで動作する必要がありますか？
* アプリケーションは、多国籍および/または国際的な環境で動作する必要がありますか？
* 想定外の本番環境の負荷がかかった場合、アプリケーションのパフォーマンスはどうなりますか？
* セキュリティ上の脆弱性からアプリケーションをどのように保護しますか？

Auth0 の [Universal Login](/docs/ja-jp/authenticate/login/auth0-universal-login) と関連する UI ウィジェット (たとえば [Lock](/docs/ja-jp/libraries/lock)) は、ユーザビリティとアクセシビリティのベストプラクティスに従ってすでに設計・構築されており、多数の [ブラウザーとデバイス](/docs/ja-jp/troubleshoot/customer-support/product-support-matrix) に対する、テスト済みの標準サポートを提供しています。[国際化](/docs/ja-jp/customize/internationalization-and-localization) (I18N) も標準でサポートされており、カスタムの多言語対応やローカリゼーション (L10N) のニーズに対応できるよう、組み込みの拡張も備えています。

機能要件が満たされ、予期しない事象が正しく処理されることを確認するために、アプリケーションと Auth0 の間の [連携](#integration-testing) をテストするためのガイダンス、および個々の拡張モジュール (たとえば [Rules](/docs/ja-jp/customize/rules/debug-rules)、[Hooks](/docs/ja-jp/customize/hooks/update-hooks)、Custom Database スクリプト) の [単体テスト](#unit-testing) に関するガイダンスが提供されています。また、セキュリティ上の脆弱性をテストする際に役立つよう、Auth0 の [penetration testing policy](/docs/ja-jp/troubleshoot/customer-support/operational-policies/penetration-testing-policy) に関するガイダンスや、想定外の負荷がかかった場合でもアプリケーションが確実に動作するよう、[負荷テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/load-testing-policy) とあわせて [モック](#mock-testing) テストをどのように活用できるかについてのガイダンスも提供されています。

<h2 id="unit-testing">
  単体テスト
</h2>

単体テストの目的は、コードの個々の単位をテストすることです。Auth0 内で Rules、Hooks、Custom DB スクリプトとしてカスタムコードを作成する場合は、そのコードをテストするために、[Mocha](https://mochajs.org/) などのテストフレームワークの利用を検討するとよいでしょう。Auth0 を最も効果的に活用している企業では、Auth0 のテナント設定や関連リソースを[自動デプロイ](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/deployment)する前に、これらの単体テストを実行することが有効だと分かっています。

<h2 id="integration-testing">
  統合テスト
</h2>

[SDLC support](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/architecture#sdlc-support) のアーキテクチャガイダンスで説明されているように、開発、テスト、本番用にそれぞれ別のテナントを設定することが推奨されています。Auth0 では、カスタム [拡張](/docs/ja-jp/customize/extensions) から利用できる変数を設定できます。これは、Auth0 テナントにおける環境変数のようなものです。開発、テスト、本番の各環境間でコードを移行するたびに変わる参照先をハードコードするのではなく、テナントで設定した変数名をカスタム 拡張 コードから参照できます。これにより、実行時にテナント固有の値が変数に設定されるため、同じカスタムコードを変更せずに異なるテナントで利用しやすくなります。

* Rules で変数を使用する場合は、[値の設定](/docs/ja-jp/customize/rules/configuration) 方法を参照してください
* Hooks で変数を使用する場合は、エディターで [secrets](/docs/ja-jp/customize/hooks/hook-secrets) を設定する方法を参照してください
* Actions で変数を使用する場合は、Explore Flows and Triggers を参照してください
* Custom DB スクリプト で変数を使用する場合は、[configuration parameters](/docs/ja-jp/authenticate/database-connections/custom-db/create-db-connection#step-3-add-configuration-parameters) を参照してください

<Tip>
  テナント固有の値や、カスタムコード内に公開すべきでない機密の secrets を保持するために変数を使用することを推奨します。カスタムコードを GitHub にデプロイしている場合は、テナント固有の変数を使用することで、GitHub リポジトリを通じて機密値が公開されるのを防げます。
</Tip>

<h3 id="test-automation">
  テストの自動化
</h3>

デプロイの自動化とテストの自動化を組み込むことで、ビルドプロセス全体を自動化できます。これにより、設定やカスタムコードの新しいバージョンを Auth0 にデプロイし、自動テストを実行できます。テストで不具合が見つかった場合は、デプロイ自動化機能を使って、最後に正常に動作していたバージョンに戻すこともできます。詳しくは、[デプロイ自動化のガイダンス](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/deployment)を参照してください。

<h2 id="mock-testing">
  モックテスト
</h2>

Auth0の[負荷テストポリシー](/docs/ja-jp/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/)といったツールも活用できます。

<h2 id="project-planning-guide">
  プロジェクト計画ガイド
</h2>

推奨戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドを提供しています。

[B2B IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)

<h2 id="multiple-organization-architecture-multitenancy">
  複数組織アーキテクチャ (マルチテナンシー)
</h2>

多くのB2Bプラットフォームでは、顧客ごとに組織の分離やブランディングを何らかの形で実装しており、その結果、Identity and Access Management (IAM) システムが複雑になることがあります。これに当てはまる場合は、この種の環境に関するガイダンスやベストプラクティスをぜひご一読ください。

[複数組織アーキテクチャ](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture)