ATFでテストを作って実行する手順：sys_atf_testを2ステップで動かす

Automated Test Framework（ATF）は、フォーム操作やAPI呼び出しに相当するテストを、コードを書かずに組み立てる仕組みです。今回検証したPDIには、テストがすでに192本入っていました。ステップの合計は2,259件、テストをまとめて実行するスイートは48件です。

ところが実行結果（sys_atf_test_result）を数えると、記録は1件しかありませんでした。中身を開くと、この記事の後半で実際に作って動かすテストそのものです。標準で入っている191本は、いまのところ一度も実行されていません。

この記事は、その1本を作って動かすところまでを追った記録です。作ったテストは2ステップだけ、実行にかかった時間は3秒でした。短いテストですが、動かしてみて初めて分かったことが1つあります。テストが作ったインシデントが、実行後にきれいに消えていたことです。

この記事で分かること

• ATFのテスト資産（sys_atf_test / sys_atf_step / sys_atf_test_suite）がどんな構造で、いくつ登録されているか

• Record InsertとRecord Queryを使い、2ステップのテストを組む手順

• Client Test Runnerでテストを実行し、結果を読む方法

• テストが実行中に作ったレコードを、実行後に自動で取り消す挙動の実測

ATFはテスト・ステップ・スイートの3層でできている

Automated Test Frameworkは、画面操作やレコード操作を「ステップ」という部品に分解し、それを並べて「テスト」を組み立てる仕組みです。ステップにはブラウザ操作を記録するもの、サーバー側の処理だけで完結するもの、REST APIのレスポンスを検証するものなど、複数のカテゴリが用意されています。

テストは単体でも実行できますが、複数のテストを1つの「スイート」にまとめ、まとめて流すこともできます。公式ドキュメントでは、この3層が次のように説明されています。

• テスト（Test）: 1つ以上のステップを順番に並べたもの

• ステップ（Test step）: フォーム入力・レコード操作・アサーションなど、テストを構成する最小単位

• スイート（Test suite）: 複数のテストをまとめて実行する入れ物

参照: Automated Test Framework

もう1つ公式ドキュメントに明記されているのが、実行に関わるシステムプロパティの存在です。ATFはインストール直後から使える機能ですが、テストランナーやスケジュール実行を許可するプロパティが別途用意されていて、環境によっては無効化されている場合があります。ここから先は、実機でその中身を確かめた記録です。

実機で確かめる：テストは192本、Activeは38本

管理画面の左メニュー「All > Automated Test Framework > Tests」を開き、Activeでグループ化すると登録数が一目でわかります。

登録されているテストは192件、そのうちActiveは38件、Inactiveは154件です。テストはsys_atf_testというテーブルの1レコードで、1本ごとにActive・Description・Packageといった項目を持ちます。

ステップは2,259件、66種類に分かれている

テストの中身であるステップは、別テーブルsys_atf_stepに入っています。testというフィールドで親のテストにぶら下がる、1対多の関係です。ステップの種類（step_config）でグループ化すると、何にステップが使われているかが見えてきます。

ステップの合計は2,259件、種類は66に分かれていました。上位に並ぶのはClick a UI Action（268件）です。次いでAssert Text on Page（Custom UI）が142件、Click Component（Custom UI）が156件と続きます。ブラウザや画面部品を直接操作するステップが上位を占める結果でした。フォーム入力を伴わないサーバー側だけの検証は、少数派だとわかります。

テストをまとめて実行するスイートは48件

Test Suitesの一覧を開くと、複数のテストをまとめる入れ物であるスイートの数を確認できます。

登録されているスイートは48件です。Child AやChild Bのように、親スイートにぶら下がる子スイートも複数あります。Filter列にsys_policy=read^nameSTARTSWITHAssessmentのような条件が入っているスイートもありました。命名規則に合うテストだけを自動的に集めて実行する使い方もできるようです。

実行を許可しているのは2つのプロパティ

テストやステップがどれだけ揃っていても、実行そのものを許可するプロパティが無効なら動きません。System Propertiesをsn_atf.runner.とsn_atf.schedule.で絞り込むと、関連する14件のうち、実行可否を左右する2つが見つかります。

sn_atf.runner.enabled（テスト・スイート実行の許可）とsn_atf.schedule.enabled（スケジュール実行の許可）は、どちらもtrueでした。このPDIでは、実行そのものが止められてはいません。

使えるステップ定義は104種類

Add Test Stepのモーダルに並ぶ選択肢の実体は、sys_atf_step_configというテーブルです。

登録されているステップ定義は104種類です。Category列を見ると、Server・Form・Service Portal・List and Related List・RESTのように操作対象ごとに分類されています。この記事で使うRecord InsertとRecord Queryは、このうちServerカテゴリに属する2つです。

テストは192本あるのに、実行結果はまだ1件だけ

ここまでの数字を並べると、テストが192本、ステップが2,259件、スイートが48件です。使えるステップ定義は104種類あり、実行を許可するプロパティも有効でした。動かす材料はすべて揃っています。

それでも実行結果（sys_atf_test_result）を数えると、記録は1件しかありませんでした。しかもその1件は、この記事の後半で実際に作って動かすテストそのものです。標準で入っている191本のテストは、このPDIでは一度も実行された形跡がありません。テストを作ることと、実際に動かしてみることの間には、思っていた以上に距離があるようです。

ここから先は、実際に手を動かしてテストを1本作り、動かすところまでの手順です。作成から実行、結果の読み方、そして実行後にレコードが自動で消える挙動まで、実画面で確認します。