仕様変更のたびにテストが壊れるのをやめる──『Web APIテスト技法』が示す設計戦略

Web API のテスト自動化に取り組んでいるのに、仕様変更のたびにテストコードが一斉に壊れて修正作業に追われる——そういう状況は、テストの設計自体に問題がある。

Mark Winteringham 著、長尾高弘訳の『Web APIテスト技法』（翔泳社、2023年）は、Postman や curl の操作方法を説明する本ではない。「何をテストするか」の選定基準から、壊れにくいテストコードの構造設計、マイクロサービス間の依存関係の検証まで、APIテストの戦略を扱う。

1. 「品質」をリスクから定義してテスト対象を絞る

本書は品質を「特定の人にとってのある時点での価値」として捉える。仕様書への適合という固定的な基準ではなく、誰にとって何が価値なのかを起点にする考え方だ。

この定義をテスト設計に適用すると、「何でもテストする」から「何を優先してテストするか」へと発想が変わる。本書はリスクを「発生確率」と「ビジネスへの影響度」の 2 軸でマッピングする手法を示す。リスクが高い領域に時間とリソースを集中し、変化が少なく影響が小さい箇所はテストの粒度を下げるという判断を根拠付きで行えるようになる。

2. Tests・Requests・Payloads の 3 層でテストの壊れやすさを下げる

自動テストが仕様変更のたびに壊れる原因の多くは、テストの検証ロジック・リクエスト処理・データ構造が 1 か所に混在していることだ。エンドポイントのパスが変わった、あるいはリクエストパラメータの名前が 1 つ変わっただけで、大量のテストが赤くなる。

本書はテストコードを「Tests（検証）・Requests（通信処理）・Payloads（データ構造）」の 3 つの層に分離する構造を提案する。リクエスト送信やペイロード構築をカプセル化することで、変更が起きたときの修正箇所を最小限に絞れる。Swagger や GraphQL のスキーマからデータ定義を自動生成する手法も取り上げており、手動での定義ミスを減らす実務的な工夫も含まれる。

3. 契約テストでサービス間の依存を検証する

マイクロサービス構成では、あるサービスの API 仕様変更が別サービスの動作を壊す。これを重いエンドツーエンドテストで検知しようとすると、実行が遅く、環境依存で不安定なテストに頼ることになる。

本書が提案するのが契約テスト（Consumer-driven contract test）だ。Pact などのツールを使い、API を提供するサービス（プロバイダー）と利用するサービス（コンシューマー）の間の合意したインターフェース要件を、コードレベルで継続的に検証する。全サービスを起動することなく、インターフェースの整合性を確認できる。

本書後半では、ビジネス側の合意をテストの期待値として記述する ATDD（受入テスト駆動開発）も扱う。テストコードを仕様の受動的な確認ではなく、チームの意思疎通を促すドキュメントにする考え方だ。

DevBookPath のマップで確認する

この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。

バックエンドの地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。