要件が変わる瞬間
リクエストを送ることで分かるのは「このエンドポイントは今どう動いているか」です。チェックが答えるのは「このエンドポイントは今も本来あるべき動作をしているか」です。後者には、前者には要らない三つのものが必要になります。期待値を置いておく場所、人手を介さずに実行する手段、そして答えが変わったことに気づく手段です。
ツールの姿が変わる理由はそれがすべてです。わざわざ言葉にするのは、多くのチームがリクエストをブックマークすることでそこに辿り着こうとするからです。
ReqBin の代替ツールが加えるべきもの
| 観点 | アドホックなリクエスト送信ツール | TestSprite |
|---|---|---|
| 得られるもの | 目視で読むレスポンス | 期待値に照らした合否判定 |
| 期待値の置き場所 | 自分の頭の中 | テストケースの中、バージョン管理下に |
| 誰が実行するか | 自分自身、思い出したときに | パイプラインが、変更のたびに |
| 複数ステップのフロー | タブ間で手作業で値をコピー | Dynamic Variables と Dependency Chains |
| クリーンアップ | 削除を思い出せた分だけ | 実行に紐づいた Auto-Cleanup |
| 通知 | なし | プルリクエストへのコメント、またはコミットのチェック |
必要なものを見極める三つの問い
これを自分以外の誰かが実行する必要はありますか。 「はい」なら、それはブラウザの外に出す必要があります。
そのフローは複数の呼び出しにまたがりますか。 リクエスト間で値を受け渡す必要が出た時点で、手作業のコピーは立ち行かなくなります。
一晩のうちに壊れたとしたら、それを知りたいですか。 そこがツールとチェックを分ける境界線です。
「はい」が一つでもあれば、リクエスト送信ツールの域をすでに超えています。三つなら、とっくに移行しておくべき状態です。
買いすぎないために
本当にときどきリクエストを投げるだけでよいのなら、そのまま続けてください。ReqBin も curl も十分に優れたツールであり、ここに書かれていることはそれらを否定するものではありません。乗り換える価値が出てくるのは、リクエストに期待値が紐づいたときであって、それ以前ではありません。
候補をどう評価するか
意図的に壊してみてください。保存したはずのものが残らない、といった実際のリグレッションを仕込み、それぞれの候補が何を報告するかを見ます。そもそも失敗として検出されるか、その失敗は実際のずれを名指ししているか、修正する人が経緯を組み立て直さずにその出力から着手できるか。アサーションに到達しないまま終わった実行を成功と報告するツールは、唯一意味のあるテストに落第しています。
多くの人が飛ばしてしまう中間のステップ
ブラウザのタブからリクエストを投げることと、本格的なテストスイートを立ち上げることの間には中間地点があります。そこを飛ばしてしまうことが、多くのチームが必要以上に長くアドホックなツールに留まる理由です。
そのステップとは、期待値をどこでもよいので書き出すことです。どのエンドポイントに、何を送り、何が返ってくるべきかを記したテキストファイルは自動化ではありませんが、ブラウザのタブにはない二つのものをすでに与えてくれます。他の人が実行できること、そして答えが変わったかどうかを判断できることです。ツールが必要だと思っているチームの多くが実際に必要としているのはこれであり、それを確かめるのにかかるのは 10 分です。
それ以上が本当に必要になるのは、手作業での実行が行われなくなったときです。これは表現力の問題ではなくスケジューリングの問題であり、本格的なテストスイートへ踏み出すことで実際に手に入るのはそこです。
使い始めるには
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルにインストールしたくない場合は、ダッシュボードでも同じ範囲をカバーできます。コマンドの全体像を確認できるのは CLI リポジトリです。
方法は二つあり、どちらを選ぶかは実質的にパイプラインを誰が所有しているかで決まります。ダッシュボードから GitHub App を接続する方法なら、リポジトリに一切変更を加える必要がありません。ビルドがすでに出力しているデプロイに反応するからです。一方、 GitHub Actions のステップを追加する方法では、チェックがリポジトリの中に入り、ビルドの他の部分と同じようにレビューされるようになります。
リクエストがチェックになると何が得られるか
期待値を置いておく場所、自分ではないトリガー、そして答えが変わったときの通知。違いはこの三つがすべてであり、TestSprite が提供しているのはまさにそれです。
複数ステップのフローはコピー＆ペースト作業ではなくなります。Dynamic Variables が識別子をある呼び出しから次の呼び出しへ引き継ぎ、Dependency Chains が何を先に実行すべきかを判断します。Auto-Cleanup は実行によって作られたものを削除するため、10 回目の実行も 1 回目と同じように動きます。
そこまでの道のりは長くありません。プロジェクトにベース URL を指定し、ディスカバリーにエンドポイントを列挙させ、計画をレビューし、リポジトリに接続して変更のたびに実行されるようにします。本当にときどきリクエストを投げるだけでよいのなら、そのまま続けてください。これは期待値が紐づいた時点のための話です。
curl は十分な代替になりますか。
リクエストを送るだけなら十分ですし、スクリプトとの組み合わせはむしろ優れています。ただし限界は同じです。期待値もスケジュールも通知もありません。
アカウントは必要ですか。
アドホックなリクエストなら不要です。自分の手を離れて実行されるチェックでは、期待値と履歴をどこかが保持する必要があり、それはサービスということになります。
共有した Postman コレクションではどうですか。
中間段階としては妥当です。リクエストを共有できるようになり、セッション、実行順序、クリーンアップは自分で保守するスクリプトになります。
最初のチェックまでにどれくらいの準備が必要ですか。
プロジェクトにベース URL を指定し、ディスカバリーにエンドポイントを列挙させ、計画をレビューします。判断を要するのはレビューの部分です。
プライベートな API もテストできますか。
到達可能なターゲットが必要です。プライベートネットワーク上のサービスの場合、API の実行には外部から到達できる環境が必要になります。