n8nのテストは、正常な一件だけでなく、欠損・再送・途中停止で外部へ何が起きるかまで確認します。ノードの成功表示と、業務として正しい結果を分けて記録することが出発点です。
入力と期待する結果を、一枚の表にする
問い合わせを台帳へ登録する例なら、受付ID・種別・本文を試験用データとして用意します。実在する顧客データを使わず、正常と不完全な入力を並べます。
| 入力・状況 | 期待する結果 |
|---|---|
| 初めての受付ID | 試験台帳へ一行だけ作成 |
| 同じIDをもう一回 | 新規行を増やさず結果を照合 |
| IDがない | 外部登録の前に確認待ちへ |
| 想定外の種別 | 未分類の出口へ |
| 外部登録の直後に停止 | 作成済みか照合してから再開 |
これは試験の設計例です。実行した結果は別列へ記録し、想定だけを合格の記録にしないようにします。
外部操作を、試験用の接続先へ置き換える
本番のメール、Slack、公開記事などへの操作は、専用アカウント・試験フォルダ・限定した送信先へ置き換えます。workflowを複製しただけでは、Credentialsや送信先が本番のまま残ることがあります。
入力固定の機能を使う場合も、固定データでの手動試験と、実際のトリガーから届く入力を分けて確認します。公式のData pinningは手動検査の補助であり、本番の入力形式を保証するものではありません。
一つのノードと、workflow全体を別々に確認する
ノード単体では成功していても、分岐の後に項目が消えたり、複数itemが別の順番になったりすることがあります。単体の入力・出力を読んだ後、トリガーから最後まで通して、件数とIDを照合します。
試験結果の記録
workflowの版：
入力ケース：
実行ID：
実際の出力件数：
外部で確認した結果ID：
期待との差分：
やり直す場合の対象ID：変更した箇所に加えて、守るべき結果を再確認する
分類条件を変えた場合は、その条件の入力だけでなく、既存の分類と未分類の例も試します。認証や外部URLを変えた場合は、誤った送信先へ届かないことも確認が必要です。
最初から大きな件数を流すより、少数の違う入力で境界を確かめてください。再送と結果不明の試験は二重実行を防ぐ設計へ、失敗後の扱いはエラー処理へつなげます。