NUnitのベストプラクティス

Question

環境：（Visual Studioのプロフェッショナル、2008年にC＃のWinFormsアプリケーション）

私はNUnitのベストプラクティスに関するガイダンスのために少し周りを掘ってきました。比較的孤立した環境で働いているソロプログラマーとして、私は集団的な知恵が私を助けてくれることを願っています。

Scott Whiteにはいくつかの良いスタートポイントがありますhereしかし、私は彼が言ったこと、特にポイント2に完全に同意していません。私の本能は、テストされるコードがテストに近いほど、あなたは完全なテストカバレッジを取得する必要があります。スコットのブログへのコメントには、パブリックインターフェイスのテストだけがベストプラクティスと見なされるという発言がありますが、テストフレームワークは典型的なクラスの消費者ではないと主張します。

NUnitのベストプラクティスとして何をお勧めしますか？

Answer 1

私はかなり似たような状況にあり、この質問は私が何をするかを説明していますkeep-your-source-close-and-your-unit-tests-closer。あまりにも多くの他の人が私のアプローチに魅了されていませんでしたが、それは私のために完全に動作します。

Answer 2

ポイント2で「ソリューションごとのビンフォルダ」を意味する場合は、私はあなたのポイントを見ることができます。個人的には、各テストプロジェクトにリファレンスを追加するだけです。一方、あなたが本当に意味するのは（1b）「あなたのテストをあなたのコードと同じアセンブリに入れないでください」私は彼に心から同意し、あなたに同意しません。コードの明快さと組織を強化するために、テストはプロダクションコードとは異なるものにする必要があります。テストクラスを分けておくことで、次のプログラマーがより簡単に理解できるようになります。テストで内部にアクセスする必要があり、内部メソッドがアセンブリに対して「パブリック」なので、Assembly.csファイルでInternalsVisibleTo構造を使用できます。

私は、コードのパブリックインターフェイスだけを単体テストするだけで十分です。適切に（TDDを使用して）、あなたのコードのプライベートメソッドは、単に以前のパブリックコードのリファクタリングとなり、パブリックメソッドを通じて十分なテストカバレッジを持ちます。もちろん、これは法律ではなくガイドラインなので、プライベートメソッドをテストしたいときがあります。そのような場合、アクセサーを作成し、リフレクションを使用してプライベートメソッドを呼び出すことができます。

私が行うもう1つの推奨は、ユニットテストとコードカバレッジを並行して使用することです。コードカバレッジは、より多くのテストが必要なときを識別するのに役立つヒューリスティックです。カバレッジの欠如は、より多くのテストが必要な場所を示すためのガイドとして使用する必要があります。これはあなたが100％カバレッジを必要としていると言うわけではありません - 一部のコードは単体テスト（自動プロパティなど）を保証しないほど単純であり、既存のテストでは触れられないことがあります。

私が記事で持っていたいくつかの問題がありました。おそらく最大のものは、単体テストのためのデータベースからの抽象化の欠如です。たぶんdbに対して踏み込む必要のある統合テストがあるかもしれません。おそらく、トリガーや制約の機能性をテストするときは、そうでなければその正確性を確信できません。しかし、一般的には、データアクセスをインターフェイスとして実装し、単体テストの実際の実装を模擬して、実際にデータベースに接続する必要はないと考えています。私のテストはより速く実行されることがわかります。したがって、私がこれを行うとき、テストをより頻繁に実行します。 "偽の"データベースインターフェイスを構築するには少し時間がかかるかもしれませんが、データアクセスに同じデザインパターンを守っている限り、再利用できます。

最後に、nUnitを使用しているかどうかにかかわらず、非常に便利なプラグインであるTestDriven.NetでnUnitを使用することをお勧めします。右クリックのコンテキストメニューでテストを実行またはデバッグするのに非常に便利です。

Answer 3

私の本能は近い テストは、あなたが完全 テストカバレッジを得るためにある 可能性が高いがテストされているコードにあることを教えてください。コメントに Scottのブログ投稿は、 の公開インターフェイスをテストするだけですが、 がベストプラクティスと考えていますが、 私はテストフレームワークが普通のクラスの消費者ではないと主張します。

パブリックエントリポイントのみを使用してコードをテストできない場合は、設計に問題があります。 TDDとSOLID principles（特に単一責任の原則と依存関係の逆転）についての詳細を読むべきです。その後、TDDのアプローチが、クラスのプライベートな部分をテストするような "ハック"を使う必要なく、よりテスト可能で、柔軟でメンテナンス可能なコードを書くのに役立つことを理解するでしょう。

私はまた、Google's guide to testability by Miško Heveryと読むことを強くお勧めします。これらのトピックをカバーするコードサンプルがたくさんあります。