TRY(試す)機能があります。この機能では、モックのuserとcontextオブジェクトを定義し、ルールに渡して実行することができます。ルールの実行が完了すると、結果の出力(コンソールのログを含む)が表示されます。これはルールの単体テストを一目で分かりやすいものにする反面、手動での作業がメインとなるため、Mochaやrewireなどのテスト自動化ツールは活用できません。
ベストプラクティスとして、また、SDLC(Software Development Life Cycle:ソフトウェア開発ライフサイクル)の推奨される対応として、運用環境への導入前にルールやルールの変更をテストする際には、Auth0で別のテスト用テナントを使用してください。
自動化
多少のボイラープレートを使用すれば、ルールがAuth0テナントに導入・実行され、変更することなく、CI/CD(継続的インテグレーションと継続的デプロイ)の自動化(単体)テスト環境で使用されるように実装できます。runInThisContextの呼び出しに渡されたオプションオブジェクトは、例外エラーが発生した際のデバッグに役立つ情報を提供します。この関数の呼び出しについては、Node.jsのドキュメントを参照してください。
ルールのテスト中に渡された最初の2つのオブジェクトはuserとcontextを表すオブジェクトです。これらはAuth0 DashboardのTRY(試す)機能と同様に、スタブで代用することができます。第3パラメーターのcallback関数は、パイプライン継続を模倣するように実装できるため、結果的に順序を追って後続のルールが実行されます。
渡されるcallback関数の中でテストを行うか、アサーションを検証することで、コールバック関数が少なくとも1回呼び出されることを検証できます。また、ルールがコールバックを複数回呼び出していないことを確認する実装を提供することもお勧めします。
さらに、Node.jsのglobalオブジェクトを使って、構成オブジェクトと、必要であればauth0オブジェクトのインスタンスにもアクセスすることができます。上の例では、(上のセクションでも説明したように)推奨基準に沿って、デバッグに役立つグローバルなconfigurationオブジェクトが定義されています。
また、上の例では、Auth0 Deploy CLIが提供するファイルシステムのディレクトリ構造を利用しています。Auth0 Deploy CLIはルールを導入するのに便利です。