自動化を作ったら、まずはdry-runを回してみますよね。実際には何も変更せず、何を処理することになるかだけを事前に確認するリハーサルです。ところがこのリハーサルが「処理対象なし」で終わると、なんだか成功した気分になります。エラーも出ていませんから。
でも実は、この状態では何も検証できていません。すべてが正常なときに入力から結果まで一気に通る経路をハッピーパスと呼びますが、パイプラインがこの経路を実際に通る姿を、まだ一度も見ていないわけです。この記事では、こういう状況で使える方法 — テスト文書を1つ自分で仕込んで、自動化をエンドツーエンドで検証する方法を整理してみます。
dry-run 0件は検証ではありません#
dry-runが候補0件で静かに終わったということは、2つのうちどちらかです。本当に処理するものがなかったか、それとも候補を探すロジック自体が壊れているか。どちらなのかは、実際の候補を入れてみるまで分かりません。
そこで必要になるのがテスト候補の仕込み(seeding)です。自動化が処理すべき条件を満たす入力を意図的に1つ作って、パイプラインの最初の実際の処理対象にするのです。たとえばマークダウンのノートをスキャンしてイシュートラッカーに自動発行するパイプラインなら、発行条件を満たすテストノートを1つ作っておく、という具合です。
このとき大事なのは、結果がどこに作られるべきかまでテスト文書に事前に固定しておくことです。「イシューができたら成功」ではなく「指定したプロジェクトにできたら成功」としておけば、成果物が見当違いの場所に作られるバグも一緒に捕まえられます。
合格基準は観測可能な成果物で書きます#
テスト文書の中には、合格基準(Acceptance Criteria)をチェックリストとして書いておくのがおすすめです。先ほどのノート発行パイプラインを例にすると、こんな基準が立てられます。
- 成果物の作成 — 指定したプロジェクトに新しいイシューが作られる
- 元データの状態更新 — テスト文書のステータス値が「発行済み」に変わる
- メタデータの記録 — 作成されたイシューのIDとURL、更新時刻が文書に残る
- 履歴の証拠 — リモートリポジトリに発行コミットが追加される
- 再実行時のskip — 同じ自動化をもう一度回すと、この文書は「発行済み」という理由でスキップされる
共通点が見えますか?どれも目で確認できる成果物です。イシューのURL、ステータス値のdiff、コミットログのように。「動いた気がする」という感覚ではなく観測可能な証拠が基準になれば、検証結果をめぐって解釈が分かれることはありません。
再実行チェックを必ず入れる理由#
5番目の項目が特に重要です。自動化は一度回って終わりではなく、繰り返し実行されますよね。2回目の実行で同じ文書がまた処理されたら、重複した成果物が積み上がり始めます。同じ入力を何度処理しても結果が一度処理したときと同じになる性質を冪等性と呼びますが、ハッピーパスの検証には「もう一度回したとき静かにスキップされるか」という冪等性の確認まで含めるのがいいんです。
スコープ外と片付け計画も一緒に書いておきます#
テスト文書には、今回の検証で扱わないこと(Out of Scope)も明記しておくのがおすすめです。たとえば他の入力の処理や、作られた成果物の後続ライフサイクル(クローズ、担当者の割り当てなど)はスコープ外、というように。範囲を狭めておけば、検証が終わったかどうかをはっきり判断できます。
検証が終わった後の片付け計画も、あらかじめ書いておきましょう。テスト文書とその成果物をアーカイブするのか、削除するのか。テスト用の成果物が実データの間に残って漂わないようにするためです。
まとめ#
自動化のエンドツーエンド検証は、こう要約できます。
- dry-run 0件は成功ではなく未検証の状態です
- 条件を満たすテスト文書を自分で仕込んで最初の候補にします
- 合格基準は観測可能な成果物(イシュー、diff、コミット)で書きます
- 再実行時のskipまで確認してこそ、繰り返し実行に安全です
- スコープ外と事後の片付け計画も文書に残します
次に自動化を作るときは、dry-runが静かに終わったからと流さずに、テスト候補を1つ仕込んで最後まで流してみてください。パイプラインが実際に仕事をする姿を一度は見ないと、信頼できないものですから。
Remember that failure is an event, not a person.
— Zig Ziglar
