[解決済み] C#とRhinoMocksを使ったテスト駆動開発のベストプラクティス【終了しました

質問

私のチームがテスト可能なコードを書くのを助けるために、私は C# コードベースをよりテスト可能にするためのベストプラクティスの簡単なリストを思いつきました。(いくつかのポイントは、C#のモッキングフレームワークであるRhino Mocksの制限に言及していますが、ルールはより一般的に適用できるかもしれません。) 誰かが従っているベストプラクティスをお持ちですか？

コードのテスト容易性を最大化するために、以下のルールに従います。

1. まずテストを書き、次にコードを書きます。 理由は？これは、あなたがテスト可能なコードを書き、コードのすべての行にそのためのテストが書かれることを保証します。

2. 依存性注入を使ってクラスを設計する。 理由: 見えないものをモックやテストすることはできません。

3. Model-View-ControllerやModel-View-Presenterを使ってUIコードとその動作を分離します。 理由 テストできない部分（UI）を最小化しつつ、ビジネスロジックをテストすることを可能にする。

4. 静的なメソッドやクラスは書かないでください。 理由 静的メソッドは分離するのが難しいか不可能であり、Rhino Mocksはそれらをモック化することができません。

5. クラスではなく、インターフェイスでプログラムしてください。 理由 インターフェースを使うことで、オブジェクト間の関係を明確にすることができます。インターフェースは、オブジェクトが環境から必要とするサービスを定義する必要があります。 また、インターフェースはRhino Mocksや他のモッキングフレームワークを使って簡単にモック化することができます。

6. 外部依存を切り離す。 理由 未解決の外部依存関係をテストすることはできません。

7. モックにしたいメソッドをvirtualとしてマークします。 理由 Rhino Mocksは仮想でないメソッドをモックすることができません。

どのように解決するのですか？

間違いなく、良いリストです。 以下はそれに関するいくつかの考えです。

まずテストを書き、次にコードを書く。

高いレベルでは同意します。しかし、より具体的に言うと、"まずテストを書き、次に 十分な そうでなければ、私のユニット テストが統合テストや受け入れテストのように見えてしまうことを恐れてしまいます。

依存性注入を使用してクラスを設計します。

同意。オブジェクトがそれ自身の依存関係を作成するとき、あなたはそれらを制御することができません。Inversion of Control / Dependency Injectionは、モック/スタブ/その他でテスト対象のオブジェクトを分離することを可能にし、その制御を与えます。これが、オブジェクトを分離してテストする方法です。

Model-View-Controller や Model-View-Presenter を使って UI のコードを動作から切り離します。

同意見です。プレゼンター/コントローラも、スタブ/モック化されたビューとモデルを渡すことで、DI/IoCを使ってテストすることができることに注意してください。以下はその例です。 まずプレゼンター TDDをご覧ください。

静的なメソッドやクラスは書かない。

これには同意しかねますね。モックを使用せずに静的メソッド/クラスをユニットテストすることは可能です。ですから、おそらくこれはあなたが言ったRhinoモック固有のルールの1つでしょう。

クラスではなく、インターフェイスからプログラムしてください。

私は同意しますが、少し違う理由もあります。インターフェイスは、さまざまなモックオブジェクトのフレームワークをサポートするだけでなく、ソフトウェア開発者に非常に大きな柔軟性を提供します。たとえば、インターフェイスなしではDIを適切にサポートすることはできません。

外部依存を切り離す。

同意。インターフェイスを使用して、外部の依存関係を独自のファサードまたはアダプタ（適切な場合）の背後に隠します。これにより、Webサービス、キュー、データベースなど、外部の依存関係から自分のソフトウェアを分離することができます。これは 特に これは、あなたのチームが依存関係 (外部) を制御していない場合に特に重要です。

モックにする予定のメソッドをvirtualとしてマークします。

これはRhino Mocksの制限事項です。モックオブジェクトフレームワークよりもハンドコーディングされたスタブが好まれる環境では、その必要はないでしょう。

そして、考慮すべき2つの新しいポイントです。

創造的なデザインパターンを使用する。 これはDIを支援しますが、そのコードを分離し、他のロジックから独立してテストすることもできます。

を使ってテストを書く Bill WakeのArrange/Act/Assertのテクニックを使う。 . このテクニックは、どのような構成が必要で、何が実際にテストされ、何が期待されているのかを非常に明確にしてくれます。

独自のモック/スタブをロールバックすることを恐れないでください。 モックオブジェクトのフレームワークを使用すると、テストが信じられないほど読みづらくなることがよくあります。自分でモックを作成すれば、モックやスタブを完全に制御することができ、 テストを読みやすくすることができます。(前項を参照ください)

ユニットテストから抽象的なベースクラスやセットアップ/ティーダウンメソッドに複製をリファクタリングする誘惑を避けましょう。