APIのtest
どういう目的に備えるためのtestか
DBをupgradeした際に、既存の全APIが壊れていないか確認したい
DBとやり取りするライブラリの整合性
SQLの書き方の変更
200かどうか、snapshot testingで事足りるmrsekut.icon
開発/本番の実環境を見る必要があるmrsekut.icon
モックじゃ意味ない
使用しているライブラリのupgrade
プロダクト内で広く使われているライブラリをupgradeした際に、既存の全APIが壊れていないか確認したい
200かどうか、snapshot testingで事足りるmrsekut.icon
開発/本番の実環境を見る必要があるmrsekut.icon
モックじゃ意味ない
CDNやProxyの存在も考慮しないといけない
生死の確認をするなら
200かどうか、snapshot testingで事足りる
実際のDB内のデータに依存する必要がない
それでも、query paramsの内容がDBに依存してしまう
特定のuserIdを指定をするとかそういうの
環境によって結果が変わりうる
開発DBには存在するが、本番DBには存在しないなど
ステータスコードが200かどうかを確認する
レスポンスのテキスト内容が期待通りかどうかを確認する
レスポンスのJSON構造が期待通りかどうかを確認する
レスポンスのヘッダが期待通りかどうかを確認する
リクエストのパスを正しく処理しているか確認する
リクエストメソッド（GET, POSTなど）を正しく処理しているか確認する
リクエストボディの内容を正しく処理しているか確認する
クラウド固有のBindings（例: KVストア）を正しく扱えているか確認する
routing周りやDBと接続する際のlibraryを変えたときに現存するAPIの挙動を確認したい
単純に固定したparamsで200が返ってくるか、期待したJSONが返ってくるかをテストすべき
ただ、DBに依存すると、DBの内容を変えるとテストが落ちる
DBの内容が変わらな限りはpassする
変わったときに面倒すぎるか?