テストを使用してフロー開発を進める

学習の目的

この単元を完了すると、次のことができるようになります。

• テスト主導型開発の原則をフローの作成に適用する。
  
• テストに対応できるようにフローを設定する。
  

このバッジは、Flow Builder のスキルを習得するための過程の一部です。Flow Builder の強力なプロセス自動化スキルを身に付けてエキスパートになるには、「Flow Builder を使用したフローの作成」トレイルに従って学習してください。このバッジに取り組む前に、そちらのトレイルを完了することをお勧めします。

最後に必ずテストを実行する

完成したばかりの美しい新しいフローを、作成が終わり次第すぐにリリースしたくなることもあるでしょう。ですが、そうしてしまうと、フローが組織のデータに予期しない変更を加えてしまうリスクがあります。そのリスクを軽減しつつ、次のことも同時に実現できる方法があるとしたらどうでしょうか。

• 各機能を個別に開発してテストすることで作業を簡素化する
  
• 追跡する変更を少なく抑えて問題をより迅速に解決できるようにする
  
• 将来のサポートや拡張が容易な、よりクリーンでシンプルな自動化を作成する
  
• 自動化の品質に集中するための専用の時間を確保する
  

こんな上手い話が、実はあるんです。多くの開発者は、テスト主導型開発と呼ばれる実証済みのリスク軽減戦略を使用して、これらすべてを実現しています。

テスト主導型開発では、自動化で実現したい結果を定義し、その結果が意図どおりに達成されていることを確認するチェックを作成してから、自動化を作成します。最後に、自動化の不要な部分や未整理の箇所を整理します。これらの作業は、機能ごとに 1 つずつ行います。

Flow Builder ではチェックを作成する前にいくつか必要な準備があるため、テスト主導型開発のプロセスを厳密にそのまま適用することはできません。フローでは、テスト主導型開発は一般的に次の手順で進めます。

1. 自動化の 1 つの機能を選択します。フローにおける機能とは、通常 1 つのデータ要素またはアクション要素です。
   
2. その機能、つまり、そのデータ要素またはアクション要素と、それを動作させるために必要なほかの要素やリソースを作成します。ただし、それらの要素に必要でないものは追加しないでください。
   
3. テストでその機能が出す望ましい結果を定義します。これには専用のツールが用意されており、これについては後ほど説明します。
   
4. テストを実行して、その機能が結果を達成しているかどうかを確認します。テストが失敗した場合 (または以前に作成したテストのいずれかが失敗した場合) は、フローに戻って更新します。すべてのテストに合格するまで繰り返します。
   
5. 作業を整理します。名前や説明をほかの人にもわかりやすくし、簡素化できるものは簡素化し、重複や不要な部分を削除します。作業の途中でもテストを実行して、すべてが引き続き正しく動作していることを確認します。
   
6. 必要に応じてこれらの手順を繰り返し、そのたびに別の機能に焦点を当てます。
   

では、フローの開発においてこのプロセスをどのように使用すればよいのでしょうか?

自動化に自動化を組み込む

レコードトリガーフローでは、Flow Builder に「Tests」というテストツールが用意されています。 Tests ツールを使用すると、テスト主導型開発のサイクルに簡単に準拠できます。ここでは、フローで実現したい結果を定義し、その結果が実際にフローによって実現されているかどうかを確認します。また、フローで想定している失敗やエラーをチェックすることもできます。

ほとんどのフローには、複数のテストがあります。Tests ツールを使用すると、1 回のクリックですべてのテストを実行できます。開発の世界では、これを自動テストと呼びます。自動テストツールでは、各結果はアサーションと呼ばれます。(アサーションの語源であるアサートとは、何かを事実として自信を持って主張することを意味します。) 自動テストツールでは、アサーションが自動化で実行されるべき事実を示し、テストがその事実確認を行います。

フローが時間の経過とともに拡張され、変更されていく中で、これまでに作成したすべてが引き続き機能していることを確認するために、テストを続行することが重要です。開発者はこれを回帰テストと呼びます。

Flow Builder の Tests 機能はレコードトリガーフローでのみ使用できますが、開発した機能が正しく動作することを手動で確認すれば、どの種別の開発でもテスト主導型開発のプロセスに準拠できます。Tests ツールは、このプロセスの一部を自動化しているにすぎません。手動テストについては、次のバッジである「フロー実装 II」で詳しく学びます。

レコードトリガーフローでは、テストを作成する前にいくつかの要件を満たす必要があります。

• フローには、[Run Immediately (即時実行)] パスに少なくとも 1 つの要素が含まれている必要があります。
  
• メールの送信や承認プロセスの開始などのアクションをテストするには、対応するアクション要素がフローに含まれている必要があります。
  
• 変数や数式などのリソースの内容をテストするには、対応するリソースがフローに含まれている必要があります。
  

これらの要件があるため、フローの作成を開始する前にテストを作成することはできません。心配はいりません。テスト主導型開発は理想形であり、重要なのは、できるだけ早くテストを作成して実行することです。

フローテストのしくみ

Flow Builder のテストでは、フローインタビューをシミュレーションするために使用するデータを定義します。これにより、テストによって組織のデータが変更されることはありません。

フローテストには、次のパーツがあります。

1. テストの詳細、トリガー、パス: テストの実行方法を定義します。
   
2. 初期トリガーレコード: フローの実行をトリガーするレコードを定義または選択します。これらの値はテストでのみ使用され、データベースには保存されません。項目で必須の値、またはテストに関連する値のみを入力します。
   
3. 更新後のトリガーレコード: レコード更新をテストする場合にのみ使用できます。フローをトリガーする更新後の、同じトリガーレコードの状態を定義します。これには、フローをトリガーした変更内容が含まれます。これらの値は、フローが実行される前のレコードの値です。
   
4. アサーション: テストが合格するために必要な条件の要件を定義します。これらの値は、フロー実行後のレコードの値です。
   

初期トリガーレコードタブと更新後のトリガーレコードタブを合わせることで、テストでシミュレーションすべきレコード更新の全体像が作成されます。初期トリガーレコードはフローをトリガーする変更前のサンプルレコードであり、更新後のトリガーレコードは、その変更後かつフロー実行前の同一レコードです。

レコード作成をテストする場合は、初期トリガーレコードのみを定義します。これは、フローをトリガーする作成済みレコードです。アサーションでは、トリガーされたフローの終了時点での項目値が、想定どおりであるかどうかを確認します。

次の単元では、フローのテストを作成し、それらを使用してフローの機能を検証します。

リソース

• Salesforce ヘルプ: 有効化前のフローのテスト
• 外部リンク: Wikipedia: Test-Driven Development (Wikipedia: テスト主導型開発)