お問い合わせ振り分けのサンプルはテストでどう動くか

このサンプルは実際に何をしたのか？

2026年10月8日に、架空の Northstar Plumbing のお問い合わせワークフローで、決めておいた5つの流れを確かめました。それぞれの流れを、リポジトリのお問い合わせのルールに対して実行し、さらに別に、ダウンロードできるスターター一式に対しても実行しました。表に記録しているのは、その限られた結果です。お客様の事例でも、本番での信頼性を示す数字でもありません。

入力と期待値は先に決めました。

情報のそろったテストデータは、alex@example.com の Alex Morgan さん、Bristol BS1、1週間ほど水が漏れ続けているキッチンの蛇口についての相談です。情報が足りないテストデータは、sam@example.com の Sam Taylor さんで、地域の記入がなく、メッセージは「Can you help?」だけです。どちらも架空の連絡先です。

重複のケースでは、Alex さんの依頼を、表示名を変え、大文字にし、余分な空白を入れて再送信します。承認の繰り返しのケースでは、すでに承認した返信を置き換えようとします。リカバリーのケースでは、模擬的に失敗させるフラグを明示的に使い、復元を飛ばそうとし、同じ記録を復元してから、あらためて承認します。

実行して、ご自身の結果と比べてみましょう。

スターター 1.0.0 をダウンロードして展開し、README に従ってください。含まれているチェックには、期待する状態とアサーションが入っています。node verify.mjs を実行すると、5つのケースすべての入力、期待値、観察した履歴を含む新しいレポートができます。失敗したケースがあると、コマンドは失敗として終了します。

リポジトリのソースでの実行は、今の TypeScript のヘルパーを直接呼び出しました。スターターでの実行は、リポジトリのファイルを読み込まずに、同梱の JavaScript を読み込みました。共通のテスト定義を使っているので比較を再現できますが、この2つの実行は、考えられるすべてのルールが正しいことを別々に証明するものではありません。

パッケージには、別に一時停止の練習もあります。

パッケージのコマンドラインのラッパーは、ローカルファイルへの保存と、一時停止・再開の操作を加えます。11個のコマンドによる練習では、記録を初期化し、失敗を模擬し、一時停止し、止められている復元を試し、再開し、復元し、2回承認し、リセットしました。一時停止中の復元は、意図どおりエラーで終了し、状態は変わりませんでした。再開しても操作が再実行されることはありませんでした。

これは成功した否定のチェックであり、報告していない失敗テストではありません。node cli-check.mjs は一時フォルダーでこの手順を実行し、終わったらそのフォルダーを削除します。これらの CLI の機能は、ブラウザーのデモにはありません。

まだ証明されていないこと

ブラウザーの重複の記憶は、リセット、再読み込み、ワークフローの切り替えで消えます。スターターはローカルファイルに保存しますが、複数人での利用のためのロックや本番用の記録の保存先はありません。メッセージが変われば新しいお問い合わせかもしれません。このキーでは、違う言葉で書かれた2つの依頼が同じ仕事についてのものかどうかは判断できません。

実際に導入するには、依頼と操作の消えない識別子、内容が変わった依頼の扱いの判断、再試行の前の送り先の確認が必要です。これらは追加が必要なものであり、今回のローカルの結果で示した修正ではありません。模擬的な失敗では何も送信しないため、操作は成功したのにその確認が失われた接続のテストにはなっていません。

この5つのケースから、お客様の作業時間の削減、成約率、実際の連携、稼働率、確実に1回だけ届くことは言えません。既存のリポジトリの単体テストでは、別にお問い合わせのヘルパーについて21個のチェックが成功しています。この広いテストは回帰を防ぐのに役立ちますが、21件のお客様での試行でも、21回のブラウザーでの利用でもありません。