自動化されたテストスクリプトを書くのは簡単です。半年後もまだその価値を発揮し続けるスクリプトを書くのが難しい部分です。多くのテストスクリプトは書かれ、一度グリーンになった後、静かに腐敗し、無関係な変更で壊れ、意味のあることを何もアサートせず、チームに赤いビルドを無視するように仕向けます。良いテストスクリプトは、正確で、独立しており、耐久性があります。
このガイドでは、自動化されたテストスクリプトとは何か、信頼性の高いスクリプトを構築する構造、APIテストスクリプトの2つの作成方法、そしてApidogでの段階的な構築について説明します。
自動テストスクリプトとは
自動テストスクリプトとは、人間の手を借りずに、ソフトウェアの一部を実行し結果をチェックする、定義された繰り返し可能な一連の指示です。スクリプトは入力を送信し、アクションを実行し、結果を期待値と比較します。一致すれば合格、一致しなければ失敗を報告します。
テストスクリプトは、テストケースの実行可能な形式です。テストケースは、意図、入力、アクション、期待される結果を人間が理解できる言葉で記述します。スクリプトはその意図を、コミットごとにマシンが実行する形に変換します。1つのテストケースが1つのスクリプトになることもあります。テストシナリオは通常、複数のスクリプトが連結されたものになります。
自動テストスクリプトの価値は、毎回同じように実行される点にあります。これは、スクリプトが決定論的に書かれている場合にのみ成り立ちます。他のスクリプトの実行順序や、以前の実行で残されたデータに依存するスクリプトは、信頼性の高い自動化ではなく、不安定な負債となります。
信頼性の高いテストスクリプトの構造
どんな言語やツールで書かれたものでも、ほとんどの優れたテストスクリプトは同じ4部構成に従っています。これはしばしばArrange-Act-Assertと呼ばれ、クリーンアップが追加されます。
Arrange（準備）。テストに必要なすべてを設定します。入力データ、認証、あらゆる前提条件などです。スクリプトは既存の状態を仮定するのではなく、独自の環境を構築すべきです。テストにユーザーが必要な場合、データベースにあるものを使用するのではなく、ユーザーを作成するか、既知のフィクスチャを使用します。
Act（実行）。テスト対象の単一のアクションを実行します。良いスクリプトは一つの動作をテストします。リクエストの送信、関数の呼び出し、イベントのトリガーなどが実行であり、スクリプトごとに正確に一つであるべきです。
Assert（検証）。期待値に対して結果をチェックします。これはチームがあまり投資しない部分です。「エラーが発生しなかった」または「ステータスが200だった」とだけ検証するスクリプトは、ほとんど何もテストしていません。強力なアサーションは、実際の値（レスポンスボディ、スキーマ、副作用、タイミング）をチェックします。
Cleanup（クリーンアップ）。スクリプトが作成したものを元に戻し、クリーンな状態から再度実行できるようにします。テストデータを残したスクリプトは、最終的に自分自身または他のスクリプトと衝突します。
耐久性のあるスクリプトと脆弱なスクリプトを分ける3つの習慣があります。1つのスクリプトにつき1つのことをテストし、失敗の原因を明確にします。スクリプトを独立させ、どのような順序でも実行できるようにします。そして、生成されたIDやタイムスタンプのような不安定なデータではなく、安定した値を検証し、実質的な理由なくスクリプトが失敗しないようにします。
APIテストスクリプトを書く2つの方法
APIテストに特化すると、2つの一般的なアプローチがあり、それぞれ異なるチームに適しています。
コードファーストのアプローチでは、汎用言語でテストスクリプトを作成します。Pythonの場合、pytestのようなフレームワークとHTTPライブラリを組み合わせることを意味し、JavaScriptの場合はテストランナーとfetchを組み合わせます。リクエスト、アサーション、セットアップを実際のコードとして記述し、スクリプトはアプリケーションとともにリポジトリに存在します。
このアプローチは、完全にプログラムによる制御を可能にします。複雑なロジック、カスタムフィクスチャ、特殊なアサーションはすべて単なるコードです。その代償として、すべてのスクリプトは記述と保守が必要なコードであり、チームにはその言語スキルが求められ、多くのボイラープレート、認証処理、リクエスト構築、レスポンス解析がスクリプト間で書き換えられます。これは、テストをコードと一緒にバージョン管理したい、その保守を担うことに抵抗がないエンジニアリングチームに適しています。
ビジュアルアプローチでは、専用のAPIテストツールでテストスクリプトを構築します。リクエストを定義し、クリックでアサーションを追加し、複数のリクエストをシナリオとして連結します。一般的なケースではスクリプトコードを記述したり保守したりする必要はありません。Apidogのようなツールはこのアプローチを採用しています。
このアプローチはボイラープレートを排除し、言語を知っている人だけでなく、チームの誰でもスクリプトを読みやすくします。ビジュアルビルダーでは表現できない稀なロジックについては、カスタムコードを使用することもあります。これは、多様なチーム、QA主導のテスト、そしてスクリプトプロジェクトなしでテストスイートを迅速に実行したいすべての人に適しています。
どちらのアプローチも間違いではありません。決定的な問題は、誰がスクリプトを保守するのか、そしてそれらがアプリケーションのリポジトリに存在するべきか、という点です。ほとんどのAPIテストでは、ビジュアルアプローチの方が信頼性の高いスイートをより早く実行でき、保守も少なくて済みます。
Apidogで自動APIテストスクリプトを作成する
耐久性のあるAPIテストスクリプトを視覚的に構築するための完全なフローは次のとおりです。
ステップ1: リクエストを定義する。OpenAPIファイルからエンドポイントをApidogに取り込むか、直接定義します。これがArrange（準備）ステップであり、リクエストはそのメソッド、パス、ヘッダー、ボディを運びます。
ステップ2: テストデータを追加する。テストするケースの入力ペイロードを設定します。多くの入力を1つのスクリプトでカバーするには、CSVまたはJSONファイルを添付して、スクリプトが行ごとに一度実行されるようにします。データ駆動型テストは、ほとんど同じような多数のスクリプトを1つに置き換えます。
ステップ3: アサーションを作成する。これが核となる部分です。視覚的なチェックを追加します。ステータスが期待されるコードと一致するか、主要なボディフィールドが存在し正しい値を持っているか、レスポンスがスキーマに準拠しているか、レスポンス時間が予算内であるかなどです。ネガティブケースの場合、失敗コードだけでなくエラーの形状も検証します。揮発性のデータを検証する衝動に抵抗してください。
ステップ4: リクエストをシナリオに連結する。実際のワークフローは複数の呼び出しにまたがります。ログインし、リソースを作成し、読み取り、削除するシナリオを構築し、あるステップから次のステップへと値を渡します。各ステップはスクリプトであり、それらが一緒になって完全なフローをテストします。
ステップ5: 必要な場合にのみカスタムスクリプトロジックを追加する。視覚的なアサーションでは表現できないチェック、条件ロジック、計算値、リクエスト間の比較には、JavaScriptのプリプロセッサーまたはポストプロセッサーを追加します。これを最小限に抑えてください。ほとんどのスクリプトには必要ありません。
ステップ6: 実行してレポートを読む。シナリオを実行します。Apidogはすべてのスクリプトを実行し、すべてのアサーションを評価し、期待値と実際値を並べて失敗した正確なチェックを報告します。
ステップ7: 実行を自動化する。シナリオをCI/CDに組み込み、コミットごとに実行されるようにします。誰かが思い出したときにしか実行されないテストスクリプトは、真に自動化されているとは言えません。最初のシナリオを構築するためにApidogをダウンロードしてください。
テストスクリプトを健全に保つ
テストスイートは生き物です。リリース時には完璧だったスクリプトも、APIの変更に伴い陳腐化していきます。次の3つの実践がスイートの信頼性を保ちます。
APIと同時にスクリプトを更新し、後回しにしないようにしましょう。エンドポイントの契約が変更された場合、同じコミットでスクリプトも変更します。古いスキーマを検証するスクリプトは間違った理由で失敗し、他のすべてのスクリプトへの信頼を損ないます。
不安定なスクリプトは実際のバグとして扱います。ほとんどの場合でパスするスクリプトは、スクリプトがないよりも悪い結果を招きます。なぜなら、チームに「赤は壊れていない」と学習させてしまうからです。通常は共有状態やタイミングの前提が原因であるため、その原因を突き止めて修正します。
本番コードのようにスクリプトをレビューします。弱いアサーションしかないスクリプト、たとえば200のチェックのみを行うスクリプトは、ほとんど何もテストしていないにもかかわらず、グリーンに見え、安全だと感じさせます。別のレビュアーがそれを指摘します。
よくある質問
テストケースとテストスクリプトの違いは何ですか？ テストケースは、意図、入力、アクション、期待される結果を人間が理解できる言葉で記述します。テストスクリプトは、マシンが実行する実行可能なバージョンです。ケースは計画であり、スクリプトは実装です。
自動テストスクリプトを書くにはコーディングの知識が必要ですか？ ビジュアルツールを使ったAPIテストでは必要ありません。Apidogでは、クリックでリクエスト、アサーション、シナリオを構築し、特別なロジックに対してのみコードを記述します。コードファーストのフレームワークでは、その言語スキルが求められます。
なぜテストスクリプトが壊れ続けるのですか？ 通常の原因は、揮発性のデータをアサートしていること、スクリプトが互いの状態に依存していること、APIの変更時にスクリプトを更新していないことです。テストデータを分離し、スクリプトを独立させ、契約に合わせて更新してください。
1つのテストスクリプトにいくつアサーションを持つべきですか？ 結果を真に検証するのに十分な数、通常はステータス、主要なボディフィールド、スキーマ、タイミングなどです。単一のステータスコードのアサーションだけでは少なすぎます。レスポンスが間違っているのにパスしてしまう可能性があります。
テストスクリプトはアプリケーションリポジトリに置くべきですか？ コードファーストのアプローチでは、通常はそうです。これによりテストはコードと一緒にバージョン管理されます。ビジュアルツールの場合、スクリプトはテストプラットフォーム内に存在し、API定義に同期されます。どちらも機能しますが、選択よりも一貫性が重要です。
APIが構築される前にテストスクリプトをどのように書けばよいですか？ API設計に対してスクリプトを作成します。OpenAPI仕様がある場合、それに基づいてリクエストとアサーションを定義し、実際のAPIエンドポイントが存在するまでモックサーバーに対して実行できます。実装が完了した瞬間にスクリプトは準備完了となります。
テストスクリプトとテストスイートの違いは何ですか？ テストスクリプトは1つのチェックを実行します。テストスイートは、まとめて実行されるようにグループ化されたスクリプトの集合体であり、しばしばAPI全体や特定の機能をカバーします。スイートは増加するスクリプトセットを整理し、1つのコマンドで広範囲のテストを実行できるようにします。
自動テストスクリプトはどのくらいの長さであるべきですか？ Arrange、Act、Assert、Cleanupの4つの部分をこなしつつ、できるだけ短くするべきです。スクリプトが長い場合、通常は複数のことをテストしており、分割する必要があります。1つのスクリプトにつき1つの動作をテストすることで、失敗の診断が容易になります。