問題
クールな REST リソース/accountがあるとします。
新しいアカウントを作成できます
POST /account
{accountName:"matt"}
次のようなjson応答が生成される場合があります。
{account:"/account/matt", accountName:"matt", created:"November 5, 2013"}
次のように呼び出して、日付範囲内に作成されたアカウントを検索できます。
GET /account?created-range-start="June 01, 2013"&created-range-end="December 25, 2013"
次のようなものも生成される可能性があります。
{accounts: {account:"/account/matt", accountName:"matt", created:"November 5, 2013"}, {...}, ...}
ここで、いくつかのサンプル データを設定し、指定された作成日の範囲内で GET /account リソースに対していくつかのテストを書きたいとします。
たとえば、どうにかして次のアカウントをシステムに挿入したい
name=account1, created=January 1, 2010
name=account2, created=January 2, 2010
name=account3, created=December 29, 2010
name=account4, created=December 30, 2010
それから電話する
GET /account?created-range-start="January 2, 2010"&created=range-end="December 29,2010"
アカウント 2 と 3 のみが返されることを確認します。
テストを作成するには、これらのサンプル アカウントをどのように挿入すればよいですか?
可能な解決策
1) 制御の反転を使用して、ユーザーが新しいアカウントの作成日を指定できるようにすることができます。
POST /account
{account:"matt", created="June 01, 2013"}
ただし、作成されたフィールドがオプションであったとしても、ユーザーがアカウントの作成日を設定できるようにしたくない場合があるため、このアプローチは好きではありません。私は確かにテストのためにそれを行うことができる必要がありますが、パブリックAPIの一部としてその機能を持っていることは私には間違っているようです. たぶん、特定の日より前に参加した人に 5 ドルのクレジットを与えたいと思います。作成日を指定できれば、ユーザーはシステムを操作できます。良くない。
2) 1 つ以上のテスト構成リソースを追加できます
PUT /account/creationDateTimestampProvider
{provider="DefaultProvider"}
また
PUT /account/creationDateTimestampProvider
{provider="FixedDateProvider", date="June 01, 2013"}
このアプローチにより、これらのリソースをセキュリティ制約でロックダウンして、テスト コンテキストのみがそれらを呼び出せるようにすることができます。構成リソース。
3) REST API を完全に回避してデータベースと直接対話し、サンプル データを設定することができました。
INSERT INTO ACCOUNTS ...
GET /account?...
ただし、これにより、REST API を使用してもアクセスできない状態になる可能性があり、db モデルが進化するにつれて、これらの SQL スクリプトを維持することも苦痛になる可能性があります。
では... GET /account リソースをテストするにはどうすればよいですか? 私が考えていない、よりエレガントな別の方法はありますか？