今回の記事を書くにあたって、「アサーション」についてあらためて勉強しました。いや、これまでも一応フローの作成＆編集をしたときは「こういうテストしてこういう結果だったよ」とお客様にはまとめてお渡ししてきたんですよ。そして開発のワークショップみたいな会に参加したときも聞いた気がする……のですが、Winter’23のプレリリース組織でこの言葉とまた再会して、理解が曖昧だったことを思い知りまして、色々調べていたら Salesforceさんのブログの例を見てなんとなく理解できました（気がします）。いつもいつもありがとうございます。
開発のバックグラウンドをお持ちの方には常識かもしれませんが、なにせ文系で生きてきました私はSalesforceの画面に登場してくれないとなかなか知る機会がなかったので、この概念を自分なりにまとめながら、Winter’23で正式リリースとなるレコードトリガフローのテストについて触ってみた感想を共有したいと思います。

レコードトリガフローで複数パターンのテストを実行して記録

リリースノートはこちら↓
◇ SALESFORCE ヘルプ＞ドキュメント＞SALESFORCE リリースノート＞Salesforce Winter’23　リリースノート＞Salesforce フロー＞Flow Builder ＞フローのテストおよびデバッグ＞フローの簡単なテスト (正式リリース)

詳細は Summer’22のリリースノートのほうがわかりやすいです。
◇ SALESFORCE ヘルプ＞ドキュメント＞SALESFORCE リリースノート＞Salesforce Summer’22 リリースノート＞Salesforce フロー＞Flow Builder ＞フローのデバッグ＞フローの簡単なテスト (ベータ)

ベータ版から変更になった点は、スケジュール済みパスがサポートされるようになったことです。素晴らしい。

フローの検証といえば「デバッグ」がずっとそばにいてくれていますが、今回の「テスト」がデバッグとどう違う良さがあるのかというと、個人的にはこの 2点かなと。

・テスト内容と結果を200までSalesforce のフローと一緒に保存できる。
・「アサーション」で、想定通りのフローとなっているかをより細かく確認できる。

プレリリース組織でテストをやってみた

複雑なフローをすぐさま組める技量がないので、シンプル過ぎてあまり参考にならずすみません😓
今回は、「商談のフェーズが「Closed Won（成立）」になったら、関連する取引先レコードの「成立済み」にチェックを入れる」トリガフローで、想定通りの操作を行って想定通りに処理がされるかを確認します。
（「レコードを更新」が新しくなったから関連レコードの更新の設定が楽ですね～）

レコードトリガフローの作成画面に、【テストを表示】のメニューが表示されていますので、そこをクリックします。

「テスト、１、２、３」の画面で【作成】をクリック。

「テストの詳細、トリガ、パスを設定」セクションです。
今回はレコードを更新したときのテストを作成します。
また、スケジュール済みパス設定してないので、「テストのパス」は「即時実行」のみです。

「最初のトリガレコードを設定」セクションです。
テストに使用するレコードを検索して選択すると、各項目にそのレコードの値が反映されます。
今回はレコードを更新した場合のテストなので、その名のとおり、更新前のレコードの状態をここで指定します。

「更新済みのトリガレコードを設定」セクションです。
レコードが更新された状態にします。
今回は「フェーズ」を「Closed Won」にしておきます。

「アサーションを設定」セクションです。
ここでは、レコードの状態や操作状況の条件を細かく定義します。定義したとおりにフローが実行されればアサーションは「合格」となり、テストの結果も合格（パス）となります。
ここまで設定したら、【保存】をクリックします。

アサーションについては、のちほど Salesforce さんのブログの例などを参照しながら、あらためて確認します。

作成したテスト一覧の画面で、該当のテストの行の【▼】をクリックし、「テストを実行して詳細を表示」を選択します。

結果が表示されます。今回はアサーション（Assertion1）は合格してフロー自体も合格です。

展開すると、デバッグ実行時のように処理の詳細が確認できます。

そして「アサーション」とは

あまり参考にならない例でさらっと説明してしまいましたが、アサーションについて、Salesforce さんのブログではこのように書かれています。

◇ Salesforce admins » Article » Why Admins Should Create Flow Tests

Lastly, we need to configure the assertions. I can hear you now, “Whoa, you’ve lost me! I’m an admin, not a developer. What’s an assertion?!” Simply put, an assertion is a way to compare the actual outcome with the predicted outcome. If they match, then assertion evaluates to true. Otherwise, the assertion fails.

↓日本語訳です。

最後に、アサーションを設定する必要があります。「おっと、話がそれてしまった！」という声が聞こえてきそうです。私は管理者であり、開発者ではありません。アサーションってなんでしょう？簡単に言うと、アサーションは実際の結果と予測された結果を比較するためのものです。もし両者が一致すれば、アサーションは true と評価されます。そうでない場合は、アサーションは失敗します。

そしてこちらの記事で例として設定されているフローとテストの内容です。

Addison will walk you through the Pickup is Not Today flow test scenario, which is one of four test scenarios she configured for her record-triggered flow. In this scenario (as shown in the test scenario path below), Addison tests that when a cupcake order is Submitted, the order method is Pickup, and the desired order date/time is Not Today, the flow will assign the cupcake order to the pickup queue and will not send the email alert to the queue.

↓日本語訳です。

Addison が「Pickup is Not Today」フローのテストシナリオを説明します。これは、レコードトリガフローに設定した 4 つのテストシナリオのうちの 1 つです。このシナリオでは (以下のテストシナリオのパスに示すように)、Addison はカップケーキの注文が送信（Submitted）され、注文方法が「Pickup」で、希望の注文日時が「 Not Today」であるとき、フローがカップケーキの注文をピックアップキューに割り当て、キューにメールアラートを送信しないことをテストしています。

画像をお借りしました

Addisonが設定したアサーションは次のとおり。

Addison writes the following assertions to ensure the record entry criteria for the flow are met and the expected outcome is achieved:
(Note: These would be equivalent to your entry criteria and post conditions in a user story for the automated process.)

・Check that the status is Submitted. (This verifies that the record is in Submitted status to trigger the flow.)
・Check that the order method is Pickup. (This verifies that the record has the Pickup order method to trigger the flow.)
・Check the variable varPickupQueueId has a value. (This verifies that the lookup of the pickup queue ID was successful.)
・Check that the email alert was not sent. (This verifies that the email alert was not sent as expected.)
・Check that the variable varPickupQueueDeveloperName is Pickup_Queue. (This verifies that the record was assigned to the pickup queue as expected.)

Addison also customizes the error message for each assertion so that anyone running the test will know why the assertion failed.

↓

Addison は、フローのレコード入力基準が満たされ、期待される結果が達成されることを確認するために、以下のアサーションを記述します。
(注: これらは、自動化プロセスのユーザーストーリーにおける入力条件とポスト条件に相当します)

・ステータスが Submitted であることを確認する。(これは、フローを起動するためにレコードが提出された状態であることを確認する。)
・注文方法が Pickup であることを確認する。(フローを起動するために、このレコードの注文方法Pickupがであることを確認する)
・変数 varPickupQueueIdが値を持っていることを確認する。(ピックアップキューIDのルックアップが成功したことを確認します。）
・メールアラートが送信されていないことを確認する。(メールアラートが期待通りに送信されなかったことを確認。）
・変数 varPickupQueueDeveloperNameが Pickup_Queueであることを確認してください。(これは、レコードが予想通りピックアップキューに割り当てられたことを確認します)。

Addison は、テストを実行する人がアサーションが失敗した理由を知ることができるように、各アサーションのエラーメッセージをカスタマイズすることもできます。

アサーションの設定画面です。

こちらも画像お借りしました。

ここまで読んでいただいた皆さん、なんとなくおわかりいただけたのではないでしょうか。
アサーション設定の例を見ると、事細かに想定する状態を定義していることがわかります。正しく値を取得できているか、その結果により正しくアクションが実行されているか（またはされていないか）、細かく確認することができます。エラーが生じた場合、エラーとなったアサーションを確認することで、原因となっている設定が特定しやすくなりますよね。

テストが便利だと思う理由

ここ最近レコードトリガフローのテストを触り始めて思うことです。
・ひとつひとつの処理の定義を再確認できるから、条件の設定漏れが減りそう。
・エラー対応が早くなりそう。
・複数の管理者がいる場合、このテストの結果が残っていると、他人が作ったフローの理解も早くなりそう。
・人によるかもしれないけれど、テスト結果見たければフローのテストを確認すればいいので、結果の共有も簡単になって素敵じゃない？

ひとこと

今のところレコードトリガフローでのみ使用可ということで、画面フローで遊んでばかりいる私はまだまだ慣れていないのですが、文系一筋できた身からすると、フローから得られる情報が増えることは大変ありがたいです。まだまだひよっこだったとき、デバッグを読んでもよくわからず、何がいけないのかを良そうして手あたり次第修正＆テストを行った日々を思い出します。😢
ワークフローとプロセスビルダーの廃止により、フローへの移行が急がれるなか、いかに効率的に確実にテストを行うか、という点も課題となってきますので、「これからフロー勉強します」という皆さま、作成して終わりではなく、テストのところも勉強しましょうね。私も勉強し直します。

フローのテストについて参考になるところ（ほぼ英語です）

◇ Salesforce ＞Trailhead ＞フローのテストと配布＞フロー動作の確認
◇ Salesforce admins » Article » Why Admins Should Create Flow Tests
◇ Salesforce admins » Article » Automate This! — Test and Debug Record-Triggered Flows with Nadina Lisbon
■ SALESFORCEBEN ＞How to Test Your Salesforce Flow

Winter’23 レコードトリガフローでの「テスト」、フローの作成＆管理に便利そう

レコードトリガフローで複数パターンのテストを実行して記録

プレリリース組織でテストをやってみた

そして「アサーション」とは

テストが便利だと思う理由

ひとこと

フローのテストについて参考になるところ（ほぼ英語です）

Winter’23関連の記事

フロー関連の記事

Winter’23　レコードトリガフローでの「テスト」、フローの作成＆管理に便利そう