7

コードでの null チェックを避けるために、メソッドが結果を返さない場合は、常に null の代わりに空のリストまたは配列を返すことをお勧めします。

Rhino Mocks はオブジェクトのデフォルト値 (リストと配列の場合は null) を返すため、多くの場合、null チェックを再度追加するか、リストを返すことを想定してモックをセットアップする必要があります。

この動作で Rhino モックを構成または拡張する方法はありますか?

var repositoryMock = MockRepository.GenerateMock<ICustomerRepository>();
IList<Customer> customers = repositoryMock.getCustomers();

Assert.IsNotNull(customers);
Assert.AreEqual(0, customers.Count );
4

3 に答える 3

0

Rhino Mocks には、問題を自動的に解決するものは何もありません。最も簡単な解決策は、SetupResult (または repeat.any) を使用してデフォルト値を構成する各タイプの拡張/ユーティリティ メソッドを単純にセットアップすることです。

ILists / Arraysをチェックし、モックを動的にセットアップすることで、常にトリッキーでメンバーを列挙することができます.これは、あなたが持っている型の数と、このユーティリティメソッドに専念できる型の数によって異なります.

幸運を！

于 2009-02-12T08:02:57.087 に答える
-1

モックのデフォルトの動作をデフォルト以外の値を返すように変更することは、危険な動きになると思います。

ICustomerRepository の実際の実装にバグがあり、空のリストを返さずに null を返すとどうなるでしょうか?

他の単体テストを作成し、空のリストを自動的に返す ICustomerRepository のモック バージョンに対してテストした場合、すべて問題ないと考えるでしょう。そのコードをビルドして、それが適切に動作すると考えて、コンパイル済みのアプリを実行するとクラッシュし始めることさえあるかもしれません。

なんで？ICustomerRepository にヒットしたクラスが null を正しく処理しなかったためです。

モック内で何か「魔法」が発生するよりも、getCustomers() メソッドから空の IList を返すようにテストで期待値を設定する方がはるかに明示的です。なんで？読みやすさが向上し、rhino にあまり詳しくない他の開発者が期待するようにコードが機能するためです。つまり、期待値のないメソッドはデフォルト値を返します。

于 2009-02-12T22:39:07.573 に答える