手動テストは、機能しなくなるまでは問題なく動作します。一人の開発者がリリース前にいくつかのエンドポイントをクリックして確認できます。しかし、12の環境で50のサービスを実行しているチームにはそれは不可能であり、彼らがそれを試みた日には、テストされていない何かがリリースされてしまいます。自動テストは、このスケーリング問題への答えです。機械に繰り返しチェックを毎回実行させることで、人間は重要な部分に集中できるのです。
このガイドでは、自動テストとは何か、それが役立つ点とそうでない点について説明し、ApidogでAPIの自動テストを段階的に設定する方法を解説します。
自動テストとは
自動テストとは、人が各ステップを手作業で実行する代わりに、ソフトウェアを使ってテストを実行し、結果を確認することを意味します。テストは一度定義します。入力、アクション、期待される結果です。それ以降、ツールは要求に応じて、スケジュールに基づいて、またはコードの変更ごとにそれを実行し、誰も見ていなくても合格か不合格かを報告します。
この変化は速度だけではありません。一貫性ももたらします。同じチェックを50回実行する人間のテスターは、毎回わずかに異なる方法で実行し、40回目には疲れてしまいます。自動テストは、50回目の実行を1回目とまったく同じように実行します。この再現性こそが自動化の真の成果です。
自動テストはスタック全体に適用されます。関数にはユニットテスト、コンポーネントには統合テスト、インターフェースにはUIテスト、エンドポイントにはAPIテストです。APIテストは、APIが安定していて呼び出しが速く、核となるビジネスロジックを担っているため、開始する上で最も価値の高い場所となることがよくあります。APIテストはミリ秒単位で実行され、不安定なブラウザと格闘する必要がありません。
チームがテストを自動化する理由
手動テストはスケールしません。 新しいエンドポイントが追加されるたびにチェックが増えます。環境が増えるたびにそれが何倍にもなります。ある程度の規模を超えると、各リリース前の完全な手動カバレッジは物理的に不可能になり、ひっそりと妥協がなされます。
自動化がなければ、デグレードがすり抜けます。 あるサービスでの変更が、3つ離れたサービスの契約を破壊することがあります。あらゆる変更に対してすべてを再実行するスイートだけがそれを検知し、その「すべてを再実行」を常に実行するのに十分なほど安価にするのは自動化だけです。
テストは再利用可能な資産になります。 手動テストは実行された瞬間に使い果たされます。自動テストは一度書けば何千回も実行されます。コストは先行投資ですが、その見返りは複利的に増えていきます。
フィードバックが高速になります。 パイプラインでテストが自動的に実行されると、開発者はコンテキストがまだ新鮮なうちに、変更が何かを破壊したことを数分で知ることができます。本番環境で見つかったバグを修正するコストは、CIで見つかった同じバグを修正するコストよりもはるかに高くなります。
人間はより良い仕事ができます。 自動化はテスターを置き換えるものではありません。退屈なクリック作業から解放し、探索的テスト、エッジケースの発見、ユーザビリティ作業など、機械が苦手なことに集中できるようにします。
自動テストが解決できないこと
自動化は無料ではなく、そうでないふりをすると失望につながります。
自動テストの作成には労力がかかり、維持にも労力がかかります。APIが変更されれば、テストも変更されます。誤った理由で失敗する古いテストスイートは、スイートがないよりも悪質です。なぜなら、チームが赤色のビルドを無視するようになるからです。
自動化は、ソフトウェアが「良い」かどうかを判断することもできません。テストに期待すると指示した内容と一致するかどうかだけを判断します。ワークフローが分かりにくいことや、応答が技術的には正しいがクライアントにとって役に立たないことには気づきません。その判断は人間が下すものです。
そして、すべてが自動化する価値があるわけではありません。2回実行するだけのチェックはそうではありません。2年間すべてのコミットで実行するチェックは間違いなくそうでしょう。まずは安定していて、反復的で、価値の高いパスを自動化し、まれな探索的作業は手動のままにしておきましょう。
ApidogでAPIの自動テストを設定する方法
ApidogはAPIの自動テストを視覚的に構築するため、動作するスイートを得るためにテストスクリプトを書いたり保守したりする必要はありません。以下に完全な流れを説明します。
ステップ1：APIを定義またはインポートします。 OpenAPIファイル、Postmanコレクションからエンドポイントを取り込むか、Apidogで直接定義します。各エンドポイントは、リクエストスキーマとレスポンススキーマを持ち、それがアサーションの基礎となります。スペックから開始すれば、API契約とテストは自動的に同期されます。
ステップ2：各リクエストにアサーションを追加します。 エンドポイントについて、アサーションパネルを開き、コードを書かずにチェックを追加します。ステータスが200に等しいか、ボディフィールドが存在し正しいタイプであるか、レスポンスがスキーマと一致するか、応答時間が予算内であるかなどです。これらの視覚的なAPIアサーションはテストの本質です。アサーションのないリクエストは、サーバーが応答したことを証明するだけです。
ステップ3：テストシナリオを作成します。 関連するリクエストを「ユーザーライフサイクル」などの名前付きシナリオにグループ化します。それらをチェーン化して、出力が下流に流れるようにします。例えば、ログインがトークンを返し、次のリクエストがそれを使用するなどです。各リクエストとアサーションのブロックがテストケースです。APIテストケースの作成方法ではその構造をカバーしています。
ステップ4：データ駆動型のカバレッジを追加します。 CSVまたはJSONファイルを添付して、1つのシナリオを多くの入力行に対して実行します。ほとんど同じ20個のケースを作成する代わりに、1つを作成し、20個のデータセットを供給します。データ駆動型APIテストは、小さなスイートで広大な入力空間をカバーする方法です。
ステップ5：シナリオを実行します。 オンデマンドで実行し、繰り返し回数を設定します。例えば50回実行して、繰り返し時の安定性を確認します。Apidogはすべてのケースを実行し、すべてのアサーションを評価し、期待値と実際値とともに失敗した正確なアサーション名を報告書にまとめます。
ステップ6：テストスイートに整理します。 シナリオをテストスイートにまとめ、API全体をワンクリックで実行できるようにします。スイートは、カバレッジが拡大しても増え続けるテストベースを管理しやすくします。
ステップ7：CI/CDに組み込みます。 これはテストスイートを自動テストに変えるステップです。コミットごとまたはプルリクエストごとにスイートを実行し、マージ前にデグレードが表面化するようにします。Apidogはあらゆるパイプラインで実行されます。CI/CDでのAPIテストの自動化でその手順を説明し、GitHub ActionsでのAPIテストの実行では、そのプラットフォームに特化して解説しています。
最初の自動シナリオを構築し、その動作を確認するためにApidogをダウンロードしてください。
自動テストの主な種類
自動テストは一種類だけではありません。それは、異なるコストで異なる種類のバグを捕捉する、階層化されたテストタイプの集合体です。
ユニットテストは、単一の関数やクラスを単独でチェックします。これらは高速で安価で、数千回実行されますが、コンポーネント同士が連携するときにのみ現れる問題は捕捉できません。
統合テストは、コンポーネントが連携して機能するかどうかをチェックします。例えば、サービスとそのデータベース、またはネットワーク境界を越えた2つのサービスなどです。これらはユニットテストでは見逃される配線上のバグを捕捉しますが、その分、実行が遅く、より多くのセットアップが必要です。
APIテストは、良いバランスの場所に位置します。実際のクライアントと同じ方法でHTTP経由でエンドポイントを操作するため、実際の契約を検証します。これらは高速で実行され、ブラウザを必要とせず、最も重要なビジネスロジックをカバーします。ほとんどのチームにとって、これは労力に対する最高の見返りが得られる層です。
エンドツーエンドテストは、実際のシステム（多くの場合UIを含む）を通じて完全なワークフローを実行します。これらは最も現実的で最も遅く、最も不安定になる傾向があるため、チームはそれらの数を少なくし、重要なジャーニーに焦点を当てます。
広く引用されるテストピラミッドは、そのバランスを捉えています。基盤には多数の高速なユニットテストがあり、中央にはより少ない統合テストとAPIテストがあり、頂上には薄い層のエンドツーエンドテストがあります。その逆、つまりほとんどが遅いエンドツーエンドテストで構成されるスイートは、実行が遅く、予測不能に失敗します。APIテストは、エンドツーエンドのコストを支払うことなく、広範囲で信頼性の高いカバレッジをチームが得られる場所であり、そのため推奨される出発点となっています。
自動化を成果につなげる
いくつかの習慣が、維持されるスイートと腐敗するスイートを分けています。
テストをAPI設計に密接に保ちます。 契約とテストが同じ場所に存在する場合、契約の変更をテストに反映させ忘れることは困難です。乖離がスイートが劣化する主な理由です。
ステータスコードだけでなく、実際の成果をアサートします。 200が返されることだけをチェックする自動テストは、ゴミが返されていても合格してしまいます。強力なアサーションを自動化しないと、誤った安心感を自動化していることになります。
失敗を読み取りやすくします。 良いレポートは、失敗したテストだけでなく、失敗したアサーションの名前を挙げます。開発者が失敗を早く読み取れるほど、チームはそのスイートを信頼します。
意思決定が行われる場所で実行します。 誰かが思い出したときにだけ実行されるスイートは自動化されていません。パイプラインに組み込み、指示がなくても実行されるようにします。
面倒な部分にはAIを活用します。 スペックからケースの初稿を生成したり、エッジケースを拡張したりすることは、アシスタンスに適しています。AIを活用したAPI自動化テストは、それが役立つ場所と人間のレビューがまだ必要な場所を示しています。
よくある質問
自動テストは手動テストより優れていますか？ どちらも他方を置き換えるものではありません。安定していて、反復的で、価値の高いチェックは自動化します。探索的テスト、ユーザビリティレビュー、判断を要する作業は手動で残します。最高のチームは両方を行います。
APIテストを自動化するにはコードの知識が必要ですか？ ビジュアルツールを使えば必要ありません。Apidogでは、クリック操作でリクエスト、アサーション、シナリオを構築し、ビジュアルビルダーでは表現できないロジックの場合にのみスクリプトに入り込みます。
チームは自動化をどこから始めるべきですか？ APIテストです。これらは高速で安定しており、UI自動化のような不安定さもなく、核となるロジックをカバーします。まず重要なエンドポイントから始め、徐々に拡大していきます。
自動テストにはどのくらいのメンテナンスが必要ですか？ APIが変更されるたびに変更が必要です。テストをAPI設計の近くに保つことで予期せぬ事態を最小限に抑えますが、継続的な時間を予算に含める必要があります。メンテナンスされていないスイートは信頼できなくなります。
自動テストが不安定になる原因は何ですか、またそれを修正するにはどうすればよいですか？ 不安定さは通常、タイミングの前提、テスト間の共有状態、またはタイムスタンプのような変動しやすいデータに対するアサーションから生じます。テストデータを分離し、変動しやすい正確な値ではなく構造をアサートし、テスト間の暗黙的な順序付けを削除することで修正できます。不安定なスイートは、チームに失敗を無視するように訓練してしまうため、不安定さは実際のバグとして扱ってください。
自動テストが機能しているかをどのように測定しますか？ リリース前にスイートが捕捉した実際のバグの数と、本番環境に漏れてしまったバグの数を追跡し、スイートの実行速度も確認します。何ヶ月もグリーンなのに本番バグがすり抜けているスイートは、あなたを守っていません。純粋なテスト数よりも、意味のあるアサーションのカバレッジが重要です。