REST API 自動テストツールまとめ


REST API のテストを自動化するためのツールを調査した結果のまとめです。

前提として、無料で使用可能なツールのみを対象としています。

分類

一口に REST API のテスト自動化といっても、様々な種類のツールがあります。
今回は独自に分類した以下の 4 種類を順に紹介していきます。

  • OpenAPI (Swagger) 連携系
  • GUI 系
  • CLI 系
  • CDC testing 系

OpenAPI (Swagger) 連携系

REST API の管理として OpenAPI (Swagger) で仕様を記述することは少なくないでしょう。
OpenAPI 連携系の API 自動テストツールでは、OpenAPI の仕様書をもとに自動テストが実施可能です。

Dredd

もともと API Blueprint のテストツールだったようですが、OpenAPI にも対応しています。
npm install のみでセットアップでき、導入は非常に簡単です。

OpenAPI 連携系のテストツール全般に言えることですが、レスポンスが定義したフォーマットに対応しているかをテストするのが中心的な用途になります。
なので、リクエスト時のパラメータを踏まえた適切なレスポンスが返ってきているか、リクエストパラメータを変えたらレスポンスが変わるのか、といったところまでテストしたい場合には相性は良くなさそうです。

参考

Swagger Test Templates

Swagger の API 仕様書をもとに自動テストを生成するツールです。

こんなに使える!今どきのAPIドキュメンテーションツール」というスライドによると、Dredd の方が使い勝手が良さそうです。

GUI 系

GUI で API をテストするためのツールにも様々なものがあります。
GUI なので、CLI 系と比較してバージョン管理や CI との相性は劣ります。

Postman

GUI で API をテストするツールとしては、Postman がかなり使われているようです。

Postman で作成した設定を CLI で実行可能になる Newman や、OpenAPI の仕様書から Postman の設定を生成する swagger2-to-postman を組み合わせることで、CI に組み込むことも可能とのことです。

参考

Restlet Client

API テスト自動化が可能な Chrome 拡張です。

参考

Katalon Studio

Eclipse ベースの IDE で、Selenium のラッパのようです。

参考

CLI 系

コマンドでテストを実行するタイプのツールです。
DSL や YAML の記述に抵抗がなければ、GUI 系よりもバージョン管理や CI 連携はしやすいです。

Karate

CLI での実行を前提とした API テストツールで最も有名なのではないかと思います。

ですが、少しだけさわってみたところ、以下の点がデメリットだと感じました。

  • セットアップ時に Java 関係の設定が必要で手間がかかる
  • 簡単ではあるものの、DSL を学ぶ必要がある

参考

Tavern

テストしたいリクエスト、レスポンスを YAML ファイルに記述して実行するだけの簡単なツールです。
pip install のみでセットアップでき、YAML も直感的に記述可能です。
「API 自動テストのための機能を最低限そろえた軽量なツール」という印象です。

参考

REST-Assured

かなり有名なツールのようです。
Karate vs REST-Assured: Comparing Powerful API Testing Frameworks」に書かれているように、Java のナレッジがある程度必要な点がデメリットだと感じました。

参考

CDC testing 系

Pact

Consumer Driven Contract testing (CDC testing) のツールです。
特にマイクロサービスにおいて、クライアント (Consumer) 側とサーバ (Provider) 側のずれが発生しにくくなることを重視したツールです。

各種言語で提供されているフレームワークで API の仕様を記述することで、API のテストとモックを同時に生成できるようです。
リクエスト・レスポンスで JSON を扱うのであれば、JavaScirpt のフレームワーク (pact-js) を使うと相性が良さそうです。

開発フローにも影響を与えうるため導入コストは高そうですが、導入さえできれば非常に強力そうです。

参考

結論

調査の結果、以下のような使いわけという結論に至りました。

GUI を使いたい場合

  • CI が不要な場合 ... Postman
  • CI でも実行したい場合 ... Postman + Newman
  • 別途 OpenAPI の仕様書を記述しており、フォーマットだけ簡易的にテストしたい場合 ... Postman + Newman + swagger2-to-postman

GUI が不要な場合

  • 別途 OpenAPI の仕様書を記述しており、フォーマットだけ簡易的にテストしたい場合 ... Dredd
  • リクエストのパラメータごとに適切なレスポンスが得られるかまで簡単にテストしたい場合 ... Tavern
  • API のモックも用意し、開発フローも整備しつつ、がっつりテストしたい場合 ... Pact

個人的には ...

個人的には Pact が気になりつつも、導入コストが高そうなため、まずは Tavern あたりから試そうと思います。

2020/10/14 追記

仕事で Tavern をしばらく使ってみたところ、テストが落ちたときの原因が非常に見にくく、結局チーム内で API 自動テストツールを自作することになりました。
Tavern のようにディレクトリ内の YAML ファイルを再帰的に読み込んでテストを実行するようなツールは、チーム内で簡単に使う程度の最低限の機能であれば簡単に作れるので、サクッと自作してしまうのもいいかもしれません。

参考