4

私はASP.NETMVCを自分自身に教えるための小さなアプリを書いています。その機能の1つは、Amazon(または他のサイト)で本を検索して「本棚」に追加する機能です。

そこで、IBookSearch(メソッドDoSearchを使用)と呼ばれるインターフェースと、次のような実装AmazonSearchを作成しました。

public class AmazonSearch : IBookSearch
{
   public IEnumerable<Book> DoSearch(string searchTerms)
   {  
      var amazonResults = GetAmazonResults(searchTerms);
      XNamespace ns = "http://webservices.amazon.com/AWSECommerceService/2005-10-05";
      var books= from item in amazonResults.Elements(ns + "Items").Elements(ns + "Item")
                 select new Book
                 {
                      ASIN = GetValue(ns, item, "ASIN"),
                      Title = GetValue(ns, item, "Title"),
                      Author = GetValue(ns, item, "Author"),
                      DetailURL = GetValue(ns, item, "DetailPageURL")
                 };
      return books.ToList();
  }

  private static XElement GetAmazonResults(string searchTerms)
  { 
      const string AWSKey = "MY AWS KEY";
      string encodedTerms = HttpUtility.UrlPathEncode(searchTerms);
      string url = string.Format("<AMAZONSEARCHURL>{0}{1}",AWSKey, encodedTerms);
      return XElement.Load(url);
  }

  private static string GetValue(XNamespace ns, XElement item, string elementName)
  {
     //Get values inside an XElement
  }

}

理想的には、最初にテストを作成して、このTDDスタイルを実行したいと思います。しかし、私は頭を動かすのに苦労していることを告白しなければなりません。

DoSearch()を実装してアドホックな本を返すFakeSearchを作成することはできますが、現時点ではそれが価値をもたらすとは思いませんか?たぶん後で、本のリストを使用するコードがあるとき。

他に何を最初にテストできますか?私が考えることができる唯一のテストは、クラウドへの呼び出しを(GetAmazonResultsで)モックし、DoSearchがLinq2XML選択を正しく実行して、正しいリストを返すことができることを確認するテストです。しかし、このタイプのテストは、コードを配置した後でしか記述できないように思われるので、をモックするかを知っています。

あなたたちと女の子がこのテストファーストスタイルをどのように回避するかについてのアドバイスはありますか?

4

3 に答える 3

3

ここでのあなたの主な問題は、いつモックコードを書くべきかを知ることだと思われます。私はあなたの主張を理解しています:あなたがまだコードを書いていなければ、どうやってそれをあざけることができますか?

答えは、ケントベックがテスト駆動開発で行っているように、非常に単純なテストでTDDを開始したいということだと思います。DoSearchを呼び出し、受け取ったものがnullではないと断言するテストを作成することから始め、それをパスするためのコードを作成します。次に、既知の検索用語に対して適切な数の本を取得していることを確認するテストを作成し、それをパスするコードを作成します。最終的には、テストに合格するために実際の有効なBookデータを受信する必要があるポイントに到達します。その時点で、DoSearchの一部が書き込まれ、それ(またはその一部)をモックすることを考えることができます。 )。

于 2009-01-16T19:03:58.507 に答える
2

検索自体をテストするためではなく、検索を使用するコードをテストする場合は、モックを作成することをお勧めします。

上記のクラスでは、次の方法でテストできます。

  • 一般的な本を検索し、見つかって有効であるかどうかを確認します。
  • ランダムな固定文字列「kjfdskajfkldsajklfjafa」を検索し、本が見つからないことを確認します

しかし..そしてこれが大きなものです。私がテストしていたクラスをモックアウトすることは決してありませんでした。それが使用したクラスをモックアウトしました。

簡単に言うと、FakeSearchは、検索ボタンが押されたときにUIが正しく機能していることをテストするときに使用されます。それが呼び出されていること、およびUIが返された本を適切に処理していることを確認できました。

お役に立てば幸いです。

于 2009-01-16T19:26:14.203 に答える
0

このクラスでは、主な焦点は、AmazonのWebサービスと正しく統合されているように見えます。そのWebサービスはあなたが所有するものではないので、それがどのように機能するかについての深い知識を持っていないので、それをあざけるべきではありません。「自分が所有するタイプのみをモックする」「サードパーティのライブラリをモックしない」など。

問題に取り組むいくつかの方法は次のとおりです。

ネットワークを介して実際のWebサービスに接続するテストを作成します。おそらく、信頼できる非常に人気のある本を探して、今後何年も続くでしょう。これにより、サービスが正しく使用されていることが保証されますが、多くの誤検知が発生する可能性もあります。たとえば、ネットワークがダウンしたり、リモートシステムのデータが変更されたりする場合があります。したがって、次のようなテストも必要になります...

実際のWebサービスからのデータに基づく静的データファイルに対するテストを記述します。テストデータを取得するには、Webサービスに手動でリクエストを実行し、ファイルに応答を書き込むことができます*。ネットワーク接続をモックする必要があります(ネットワークを使用しないスタブを使用するか、テストで組み込みWebサーバーを起動して、実際のURLの代わりに接続します)。このようにして、あらゆる種類のコーナーケースとエラー状態を簡単にテストでき、実際のWebサービスに何が起こっても、データは常に利用可能であり、同じままです。注意点の1つは、実際のWebサービスのAPIが変更された場合、これらのテストはそれに気付かないため、実際のWebサービスに対して作成されたいくつかのテストも必要になることです(前述のとおり)。

*たとえば、cronと小さなシェルスクリプトを使用して、数分ごとにWebサービスからデータをダウンロードしました。このデータには、常に変化するスケジュール情報が含まれていました。このようなデータを数週間収集することは、テストデータとして非常に役立ちました。そのデータから、実際のデータで気付いたあらゆる種類の特殊なケースを含む静的応答を手作りしました。また、偽のWebサービスと、以前にキャプチャしたデータを再生する「タイムマシン」を設定して、実際のWebサービスにアクセスせずにシステムを使用できるようにする場合にも役立ちました。

于 2011-06-16T21:15:44.447 に答える