テストの練習に使える公開API

この公開APIリストの使い方

APIを1つ、スキルを1つ選んでください。そのうえで3つのケースを書きます。正常系、エッジケースを1つ、そして失敗を予期して、その失敗が正しい形になっているかを検証するケースを1つです。3つ目は多くの人が省いてしまうケースであり、バグを見つけられるテストスイートと、サービスが動いていることを確認するだけのテストスイートを分けるものです。

始める前に一点だけ。ここで紹介するのは、有志や企業が好意で運営している共有サービスです。リクエスト量は控えめにし、負荷生成ツールを向けることは避け、可能な場合はレスポンスをキャッシュしてください。

リクエストとレスポンスの基本を学ぶなら

• JSONPlaceholder。 投稿、コメント、ユーザー、ToDoを扱うダミーのREST APIです。書き込みも受け付けますが、保存されたように振る舞うだけです。 練習できること: CRUDの各メソッド、ステータスコード、そしてリクエストが成功したことと変更が永続化されたことの違い。書き込みが実際には保存されないという性質のおかげで、レスポンスではなく結果を検証することを学ぶ教材として、際立って優れています。

• HTTPBin。 送ったものをそのまま返すエンドポイントに加えて、指定したステータスコードを返す、わざと遅延する、壊れたペイロードを返すといったルートが用意されています。 練習できること: タイムアウト、リトライ、リダイレクトの処理、ヘッダーの挙動。テストスイートが503にどう反応するかを確かめたければ、必要なときに503を発生させられます。

• REST Countries。 安定していてドキュメントも整った構造の国データを、キーなしで利用できます。 練習できること: スキーマの検証と、フィールド単位のバリデーション。ペイロードは扱いがいのある大きさでありながら、目で追える程度の小ささです。

ページネーションと大きなコレクションなら

認証とレート制限なら

どの公開APIでも練習する価値のある3つの検証

どのサービスを選んだとしても、ここで身につく習慣は自分のAPIにそのまま活きます。

• ステータスだけでなく、ボディも検証しましょう。 レコードが入っているはずの場所に空のリストが入ったまま200が返ってくるのはバグですが、ステータスコードだけを見る検証はこれを平然と合格と判定します。この習慣ひとつで、他のどの習慣よりも多くの実際の不具合を見つけられます。

• 失敗が正しく失敗することを検証しましょう。 存在しないものをリクエストして、正しいコードと扱えるエラー構造が返ってくるかを確認してください。エラーオブジェクトを含んだまま200を返すサービスは珍しくなく、それを知らないテストスイートはいつまでもグリーンを報告し続けます。

• フィールドだけでなく、関連も検証しましょう。 投稿がユーザーを参照しているなら、そのユーザーを取得して実在するかを確認します。興味深いバグの多くは、1つのエンドポイントの内側ではなく、2つのエンドポイントの間に潜んでいます。

エージェントを向けてみる

自分のサービスで試す前に、自動生成されたカバレッジがどんなものかを見てみたいなら、公開APIは安全な試し場所です。汚してしまうデータもなければ、壊してしまう環境もありません。

プロジェクトをベースURLに向け、ディスカバリーにエンドポイントを洗い出させたら、何かを実行する前に生成されたプランを読んでみてください。面白いのはこのプランです。進めながら注目すべき点が2つあります。

• 値をハードコードせずに取得しているでしょうか。 作成のリクエストは識別子を返し、次のリクエストはそれを使うべきです。識別子がハードコードされていることが、テストスイートが一度しか通らない典型的な原因です。

• 依存関係のあるリクエストを正しい順序に並べているでしょうか。 作成されていない投稿へのコメントは取得できません。プランがそれを理解しているのか、それとも単にエンドポイントをアルファベット順に並べているだけなのかを見てください。

そのうえで実行し、失敗の内容を読みます。公開APIでは、失敗の多くはサービス側ではなく自分の思い込みに起因します。それこそが学びどころです。

テストコードを自分で持ちたい場合、バックエンドの作業についてはCLIが別の道を用意しています。リクエストと検証はPythonで自分で書き、各テストが必要とするものと生み出すものを宣言し、クリーンアップも1つのテストとして指定します。最初の手間は増えますが、テストスイートは自分のリポジトリに置かれます。これを望むチームもあれば、望まないチームもあります。

練習から自分のサービスへ

公開APIで練習することと、自分のAPIをテストすることの隔たりは、見た目より大きいものです。どこで難易度が跳ね上がるのかを知っておくと、無用な苛立ちを避けられます。

公開APIは、利用する側から見ればステートレスです。読み取るだけで、書き込んだものは残らないか、残っても問題になりません。自分のサービスはその逆です。実際のものをテストし始めた瞬間から、期限切れになる認証、他のレコードより先に存在していなければならないレコード、実行時にしか存在しない値、そして後片付けの義務がついて回ります。

どれもチュートリアルには出てきませんが、どれも最初の1週間で出てきます。ですから、公開APIの段階は検証を学ぶ期間と考えてください。検証の力はそのまま活きます。一方で状態の扱いは、同じスキルの延長ではなく、そのあとに別途学ぶものだと考えておくとよいでしょう。

やってはいけないこと

• 負荷テストに使わないでください。無料で共有のサービスであり、その費用は誰かが負担しています。

• 本番環境の依存先にしないでください。利用規約は変わり、プロジェクトはアーカイブされ、有志は疲れます。

• JSONPlaceholderに対してテストスイートが通ったことを、自分のAPIが正しい証拠と考えないでください。それが示すのはテストの構成が動いているということであり、確かに有用ですが、はるかに小さな主張です。

実際のサービスで試す

検証の習慣が身についたあと、自分のAPIへ移った時点で状態の問題が始まります。そこを製品として引き受けるのがTestSpriteです。Auto-Authenticationは実行を通してセッションを維持します。Dynamic Variablesは作成リクエストで得た識別子を削除リクエストへ引き渡します。Dependency Chainsは何を先に行うべきかを判断します。Auto-Cleanupは実行中に作られたものを削除します。

自分のサービスで始める手順は、先ほどの公開APIでの練習と同じです。プロジェクトをベースURLに向け、ディスカバリーにエンドポイントを洗い出させ、何かが実行される前に生成されたプランを読みます。違うのは、プランが認可や境界値のケースまで含むようになることと、実行後に何も残らないことです。

汚してしまうデータがないので、まず公開APIで試してみるのが安全です。しかも、ツールの実力は結果よりもプランのほうがよく語ってくれます。