安らかなWebサービスをユニットテストする適切な方法を誰かが知っているかどうか疑問に思います。休憩を使用して構築された一連のWebサービスがあり、それらのテストコードを記述したいと思います。残念ながら、私のWebサービスはデータベースに関連付けられているため、テストでデータベースにデータが入力されることになり、問題のように見えます。
私は主に、単体テストの観点からこれに対処するための適切なアプローチについて質問しています。テスト後に挿入した値のデータベースをクリアしますか？特別なテストルートのセット全体を含む特別なテストデータベースはありますか？私はこれにアプローチするための最良の方法について少し途方に暮れています。
明らかに、同様のデータベースラッパークラスの他のケースでは、テストの開始時に設定したダミーデータベースを渡すだけです。これは、休憩のような安らかなフレームワークで作業することになると、はるかに難しいように思われます。
データベースに情報を保存するテストを処理する正しい方法について、皆さんが考えていることを感謝します。
前もって感謝します。
通常、Web サービスをテストするときは、外側から内側へと完全なスタックをテストします。これは、リソースを要求し、結果が期待どおりかどうかを確認することを意味します。
ほとんどの場合、すべてのリクエストの直前にデータベースにデータを入力するのが適切な方法です。やり過ぎのように思えるかもしれませんが、実際には Web サービスでは、さまざまな要素をモック/スタブ化することによって、適切なテスト カバレッジを保証することはできません。
Ruby の世界から来たCucumberは、高レベルからテストできるため、理想的なアプローチです。これをRspecと組み合わせて実際の単体テスト (オブジェクトを直接クエリする下位レベルのテスト) を行うと、両方の長所が得られます。これらのライブラリには、データベースへの入力と削除を管理する「データベース クリーナー」と呼ばれるものも付属しています。
Rspec の作成者による次のブログ投稿は、あまりモックやスタブ化を避ける必要がある理由を見事に説明しているため、非常に役立つかもしれません。http://blog.davidchelimsky.net/2011/09/22/avoid-stubbing-methods-invoked-by-a-framework/
一般的に言えば、次の 2 つのオプションがあります。
1) 期待値を設定できる既知のデータを含む専用のテスト データベースを使用します。テストを開始する前に、DB を「元の DB」に置き換えます。実際にはデータベースに依存しているため、これは統合テストと見なされます。
2.) コードを実際のデータ ストアから独立させ、依存関係を永続化レイヤーに渡します。単体テストでは、単体テスト中の状態の変化を観察できるカスタム永続化レイヤー/オブジェクトを作成 (またはモックアウト) できます。
シナリオに応じて両方を適切に組み合わせると、通常は適切なカバレッジが得られます。
また、Restful Web サービスをテストする代わりに、各サービス エンドポイント内の POCO に委任し、これらの POCO を直接テストすることを検討してください。はるかに簡単にテストでき、あとはサービス エンドポイントと POCO 間のマッピングを確認するだけです。
私の理解では、この順序でテストを実行すると、すべての動詞をテストできますが、最後に DB に追加のデータはありません。
POST ( add a new record)
GET ( fetch the newly added record)
PUT/PATCH ( modify the newly added record)
DELETE (delete the newly added record)
もちろん、同時にデータベースを使用している他の誰かが、テスト中に一時的な値を目にする可能性があります。