APIテスト: 最初にやること、次にやること、まだやらなくていいこと

APIテストに含まれる5つの活動

• 機能テスト。 単一のエンドポイントが、不正な入力を与えた場合も含めて正しく動作するかを確かめます。ここから始めてください。ほかのすべては、これができていることを前提としています。

• 統合テスト。 一連の呼び出しが正しい結果を生むかを確かめます。ユーザーの目に触れるバグの多くは、実際にはここに潜んでいます。

• 契約テスト。 2つのサービスがデータの形について合意できているかを確かめます。サービスを独立にデプロイしている場合には価値がありますが、正しさそのものは見えません。

残りの2つは 負荷テストです。これは処理能力に関する問いに答えるもので、専用の負荷生成ツールを必要とします。そしてもう1つが セキュリティ上の振る舞いです。その大半は認可のチェックであり、四半期に一度の特別な作業としてではなく、機能テストのカバレッジと並べて扱うべきものです。

取り組む価値のある順序

1. 重要なエンドポイントに対する機能テスト。 異常系のケースも含めます。ほかのすべては、この上に積み上がります。

2. 実際のユーザージャーニーに対する統合テスト。 1本あたり3〜5ステップであり、12ステップではありません。

3. あらゆる箇所での認可チェック。 コストが低く、しかもオブジェクトレベルの認可は、APIの欠陥のなかで最も悪用されやすいものです。

4. サービスを独立にデプロイしているなら、契約テスト。 すべてをまとめてデプロイしているなら、これは省いて構いません。

5. リリース前の負荷テスト。 最後に回します。正しく動かないエンドポイントに負荷をかけても、どれだけ速く間違えられるかを測るだけだからです。

どのツールを選んでも避けられない4つの問題

APIテストスイートが最初の1年を生き延びられるかどうかは、4つの要素で決まります。期限切れになるセッション、実行時にしか存在しない値、互いに依存する呼び出し、そして誰も片付けないレコードです。TestSpriteはこれらをAuto-Authentication、Dynamic Variables、Dependency Chains、Auto-Cleanupとして扱います。詳細は APIテストのドキュメントで解説しています。

どのチームも同じ順番でこれらに出会い、その多くは不意打ちとして遭遇します。最初からこれらを見越して設計できているかどうかが、長く使えるスイートと、隔離されて放置されるスイートを分けます。

最も重要なアサーション

ステータスコードだけでなく、レスポンスボディに対してアサーションを書いてください。レコードが返るべき場所で空のリストを返す200はバグですが、ステータスだけを見るチェックはこれを合格と判定します。この習慣ひとつで、ほかのどんな単一の変更よりも多くの実際の不具合を見つけられます。

最初の10ケース、具体的に

スイートがまだ空の状態では、どこから手を付けるかを決めることが最も難しく、一般論めいた答えでは1週間を無駄にします。ここでは、多くのプロダクトでうまく機能するリストを挙げます。

プロダクトの中心となるオブジェクトに3ケース。作成する、取得してフィールドをアサートする、削除して消えたことを確認する、の3つです。認可に2ケース。同じ取得を認証情報なしで行う場合と、別のユーザーの認証情報で行う場合です。入力に2ケース。必須フィールドが欠けている場合と、値が範囲外の場合です。リリース前に不安を感じるシーケンス——それが何であれ——に2ケース。そして、前回壊れたエンドポイントに1ケースです。

10ケース、午前中で終わる程度の作業量で、多くの障害を生むパターンをカバーできます。そこから先の拡張は、カバレッジの目標に向かってではなく、実際に起きた問題を起点に進めるべきです。後者のやり方は、規模ばかり大きくて的を外したスイートを生むからです。

今日から始めるには

プロジェクトを自分のサービスに向け、ディスカバリーに存在するものを列挙させ、何かを実行する前に生成されたプランを読んでください。最初の実行結果よりも、プランのほうが自分のAPIについて多くを教えてくれます。そして、プロダクトの知識を加えるべき場所もここです。

何もインストールしたくない場合は、ダッシュボードから同じことができます。コマンドラインでできるそのほかの操作については、 CLIリポジトリにすべてまとめています。

• GitHub App は、TestSpriteのダッシュボードで設定するWebhookです。すでにパイプラインが発行しているデプロイイベントを待ち受けるため、リポジトリ側には何の変更も必要ありません。

• GitHub Actions は、自分のワークフローの中にそのステップを組み込む方法で、設定はターミナルから行います。

5つの活動のなかでTestSpriteが担う範囲

機能テスト、統合テスト、そしてセキュリティのうち振る舞いに関わる部分です。稼働中のサービスを実際に動かし、ディスカバリーの結果と仕様からプランを生成し、手書きのスイートでは飛ばされがちな異常系のケースまでカバーします。

Auto-Authenticationは実行中セッションを維持し、Dynamic Variablesは呼び出しのあいだで値を受け渡し、Dependency Chainsは各ケースが必要とするものと生成するものから実行順序を導き、Auto-Cleanupはその実行で作成されたものだけを削除します。どのツールであれ、スイートが最初の1年を生き延びられるかを決めるのはこの4つであり、これらが製品機能として備わっているかどうかが、スイートを育てていく作業と、スイートの維持に追われる作業との分かれ目になります。

契約テストと負荷テストは別の道具のままであり、これはその両方と並行して動きます。得られるのは、ユーザーの目に触れる不具合の大半が存在する層を、自前のフレームワークを持たずにカバーし、すべてのプルリクエストで実行できる状態です。