APIテストにSeleniumは使える？使うべき？

Seleniumは、ブラウザ自動化フレームワークです。人のようにボタンをクリックしたり、フォームに入力したり、レンダリングされたページを読み取ったりして、Chrome、Firefox、その他のブラウザを操作します。これはエンドツーエンドのUIテストの標準ツールであり、その役割において非常に優れています。

SeleniumでAPIをテストできるか、という質問は今でもあります。正直な答えは、HTTP呼び出しを発行させることはできますが、その作業には間違ったツールだということです。このガイドでは、それがなぜなのかを正確に説明し、SeleniumによるAPIテストが実際にどのように見えるかを示し、その目的に合ったツールを紹介します。目標は、後であなたを苛立たせるであろう設定を避けることです。

SeleniumとAPIテストが合わない理由

APIテストは、HTTPリクエストを直接サーバーに送信し、その応答（ステータスコード、ヘッダー、ボディ、タイミング）をチェックします。ユーザーインターフェースは関与しません。テストは高速で、分離されており、何千回も実行しても安価であるべきです。

Seleniumは、設計上、その逆を行います。実際のブラウザを起動し、ページをロードし、JavaScriptがレンダリングされるのを待ちます。ブラウザはUIをテストする際にはその目的全体ですが、APIをテストする際には純粋なオーバーヘッドです。専用のクライアントが数十ミリ秒で送信するリクエストは、ブラウザプロセス、WebDriverセッション、およびページレンダリングが関与すると、数秒かかる処理になります。

さらに深い不一致もあります。SeleniumのAPI全体は、ページ上の要素に関するものです。このボタンを見つける、このテキストを読む、この要素を待つ、といった具合です。HTTP応答はページではありません。DOMもありません。そのため、SeleniumはJSONボディの検査、ヘッダーのアサーション、ステータスコードのチェックに役立つものを何も提供しません。結果として、ツールを使って作業するのではなく、ツールの回避策を講じることになります。

コストは速度だけではありません。ブラウザベースのテストは不安定であることで有名です。ページがレンダリングに少し時間がかかったため、WebDriverセッションが切断されたため、またはブラウザのアップデートによってタイミングが変更されたため、テストが失敗します。APIテストは決定的であるべきです。同じリクエストは同じ応答を生成し、失敗は何か本当に壊れたことを意味します。Seleniumを介してAPIチェックを行うと、ブラウザの不安定性が全く不安定である必要のないレイヤーにすべて持ち込まれてしまいます。時間が経つと、不安定なテストスイートは、チームに赤いビルドを無視するように仕向け、テストの目的を損ないます。検証と確認の違いは、ここで良い視点となります。Seleniumはレンダリングされた体験を「確認」しますが、APIテストはその基盤となる契約を「検証」します。

「SeleniumによるAPIテスト」が実際に意味するもの

記事がSeleniumでAPIをテストできると主張する場合、通常は2つの回避策のいずれかを意味します。どちらもSeleniumをAPIテストツールにするものではありません。それらは単にHTTPをそれを通して、またはそれと並行してルーティングしているだけです。

選択肢1：SeleniumのJavaScriptエグゼキュータを使用する。 Seleniumは、制御するブラウザで任意のJavaScriptを実行できます。モダンブラウザにはfetch APIがあるため、ブラウザにリクエストを作成させ、その結果をテストコードに返すように依頼できます。

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

これは機能します。しかし、これは、通常のHTTPクライアントが直接行うHTTP呼び出しを1つ行うためだけに、ブラウザ、WebDriver、およびJavaScriptブリッジを開始したことを意味します。また、サーバー間のAPIテストでは考慮する必要のないCORSなどのブラウザの制約も継承します。

選択肢2：Seleniumを無視し、その横で実際のHTTPライブラリを使用する。 Javaプロジェクトでは、これはAPI部分にSeleniumとREST Assuredを組み合わせることを意味します。

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

ここでの実際のAPIテストは完全にREST Assuredによって行われていることに注目してください。Seleniumは何も貢献していません。2つのライブラリはたまたま同じプロジェクトに存在するだけです。これは問題ありませんが、「SeleniumによるAPIテスト」ではありません。これは適切なAPIテストライブラリによるAPIテストであり、Seleniumは無関係なUIテストのために存在しているだけです。

それらを組み合わせるのが妥当な場合

Seleniumスイート内でHTTP作業を行う正当なケースが1つあり、それを明確にすることは重要です。Selenium UIテストでは、ブラウザを介するよりもAPIを介する方が高速なセットアップまたはティアダウンが必要になることがよくあります。

注文履歴ページをチェックするUIテストがあるとします。それをテストするには、注文が存在する必要があります。その注文を作成するためだけにブラウザでチェックアウトフロー全体をクリックするのは、遅くて壊れやすいです。代わりに、テストは直接API呼び出しを行って注文を作成し、その後、純粋にブラウザを必要とする部分、つまり履歴ページをロードして注文が表示されることを確認するためにのみSeleniumを使用します。

これは健全な実践です。API呼び出しは目的を達成するための手段であり、テスト対象ではありません。API呼び出しは、JavaScriptエグゼキュータではなく、引き続き実際のHTTPクライアントを介して行われるべきです。したがって、この場合でも、SeleniumはAPIテストを行っているわけではありません。UIテストを行っており、適切なHTTPクライアントがAPI側を処理しています。

この「APIによるセットアップ」パターンは非常に一般的であり、ほとんどの成熟したテストスイートは意図的にそれを取り入れています。これにより、スイートの遅い、ブラウザ駆動の部分が可能な限り小さく保たれ、実際にレンダリングされたページを必要とする少数のジャーニーに限定されます。データ準備とほとんどの検証を含むその他すべては、高速なHTTP呼び出しを介して行われます。その結果、数時間ではなく数分で実行され、真の理由で失敗するスイートが生まれます。UIと自動化レイヤーがどのように連携するかというより広い視点については、機能テストと自動テストを参照してください。

APIテストのために作られたツールを使う

APIをテストすることが目標であれば、そのために設計されたものを使用してください。その違いは小さくありません。真のAPIテストツールは、ブラウザを起動することなく、リクエストの構築、環境管理、ステータス、ヘッダー、ボディに対するアサーション、リクエストの連鎖、データ駆動型実行、CI連携を提供します。

選択肢はいくつかのグループに分けられます。

コードを好むなら、JavaのREST Assured、Pythonのrequests、NodeのsupertestのようなHTTPライブラリが適切です。これらのライブラリはリクエストを行い、応答を直接返します。ステータスコードやJSONボディのためのアサーションヘルパーも組み込まれています。ブラウザもWebDriverもレンダリングもないため、完全なスイートは高速に実行され、API自体が変更された場合にのみ失敗します。

ビジュアルワークスペースが必要な場合は、ApidogがオールインワンのAPIプラットフォームであり、APIの設計、リクエストのデバッグ、エンドポイントのモック、自動テストシナリオの構築、ドキュメントの生成をすべて1つのプロジェクトでカバーします。アサーションを視覚的に、またはスクリプトで構築し、リクエストを多段階のフローに連鎖させ、データ駆動型イテレーションを実行し、CIですべてを実行できます。OpenAPIおよびPostmanファイルもインポートできるため、既存のAPIをすばやく取り込むことができます。そのどれもブラウザは関与しません。なぜなら、そのどれもブラウザを必要としないからです。Apidogをダウンロードして実際のAPIで試すことができます。

コードファーストのフレームワークを望むチームには、API自動化のためのRobot FrameworkとAPI自動化テストフレームワークの構築に関するガイドが、Seleniumとは異なり、HTTPテストに実際に適したアプローチをカバーしています。

正直な結論

Seleniumは、ブラウザを自動化するという、その目的のために作られたものとしては優れたソフトウェアです。APIテストはそれとは異なります。技術的にはSeleniumのJavaScriptエグゼキュータを介してHTTPをプッシュすることもできますし、HTTPライブラリをSeleniumと同じプロジェクトに置くこともできますが、どちらの場合もSeleniumがAPIテスト自体に価値を加えることはありません。

間違ったツールを選択することは、中立的な決定ではありません。それはテストを遅くし、保守を困難にし、APIとは関係のない障害が発生しやすくなります。その仕事のために作られたツールを使いましょう。テストスイートはより高速で信頼性が高く、理解もはるかに容易になります。最高の自動テストプラットフォームのまとめは、目的に特化したオプションを比較するのに良い場所です。

よくある質問

SeleniumでREST APIをテストできますか？

ブラウザのJavaScriptエグゼキュータを介してHTTPリクエストを発行できるので、狭い技術的な意味では「はい」です。しかし、Seleniumには応答を検査したり、JSONについてアサートしたり、ヘッダーをチェックしたりする機能がなく、ブラウザの完全なオーバーヘッドを伴います。これはREST APIテストツールではなく、それとして使用すると、遅く、壊れやすいテストが生まれます。

なぜ一部のチュートリアルではSeleniumとREST Assuredが一緒に示されているのですか？

それらのチュートリアルでのAPIテストは、実際のHTTPテストライブラリであるREST Assuredによって完全に実行されているからです。Seleniumは、無関係なUIテストのために同じプロジェクト内に存在するだけです。この組み合わせは問題ありませんが、SeleniumがAPIをテストしているという意味ではありません。REST Assuredがテストしています。

SeleniumテストでAPI呼び出しを行うのは問題ないですか？

はい、セットアップとティアダウンのためなら問題ありません。APIを介してテストデータを作成する方が、UIを介してクリックして作成するよりも高速で信頼性があります。API呼び出しは、テスト対象であるというよりも、UIテストをサポートするものであり、引き続きSeleniumのJavaScriptエグゼキュータではなく、適切なHTTPクライアントを使用すべきです。

APIテストにはSeleniumの代わりに何を使うべきですか？

コードファーストのテストには、REST Assured、Pythonのrequests、NodeのsupertestなどのHTTPライブラリが適しています。ビジュアルワークスペースには、Apidogのような専用APIプラットフォーム、またはPostman、Insomnia、Talend API Testerのようなクライアントが適しています。これらはすべてHTTP用に構築されており、Seleniumが課すブラウザのオーバーヘッドを回避します。

APIテストにSeleniumを使用すると、CIパイプラインが遅くなりますか？

著しく遅くなります。SeleniumベースのAPI呼び出しごとにブラウザプロセスとWebDriverセッションが開始され、1秒未満のHTTPリクエストが数秒かかる操作になります。スイート全体では、それが積み重なり、パイプラインの実行が長く、不安定になります。専用のAPIテストツールは、ブラウザを起動しないため、同じチェックをはるかに高速に実行します。