単体テストのガイドラインと推奨事項がどこにあるか知っている人はいますか? 次の種類のトピックに対応するものを用意したいと思います (たとえば)。
私は何を求めていないのですか？
オンライン リソースが最適です。
Kent Beck のTDD に関する本をお勧めします。
また、 Martin Fowler のサイトにアクセスする必要があります。彼はまた、テストに関する多くの良い情報を持っています。
私たちは TDD をかなり重視しているので、その観点から質問に答えます。
テストはアプリケーション ロジックと同じプロジェクトにある必要がありますか?
通常、テストは同じソリューションに保持しますが、テストを、テストしている DLL/プロジェクトをミラーリングする個別の DLL/プロジェクトに分割しますが、テストがサブ名前空間にある名前空間を維持します。例: Common / Common.Tests
ロジック クラスをミラーリングするテスト クラスを用意する必要がありますか?それとも必要な数だけテスト クラスを用意する必要がありますか?
はい、クラスを作成する前にテストを作成する必要があります。定義により、単一のユニットのみを分離してテストする必要があります。したがって、ソリューション内のクラスごとにテスト クラスが必要です。
テスト クラス、メソッド、およびプロジェクトにどのように名前を付ける必要がありますか (それらが別のプロジェクトにある場合)
私は動作がテストされるものであることを強調したいので、通常は SUT にちなんでテスト クラスに名前を付けます。たとえば、 User クラスがある場合、テスト クラスに次のような名前を付けます。
public class UserBehavior
メソッドには、期待する動作を説明する名前を付ける必要があります。
public void ShouldBeAbleToSetUserFirstName()
プロジェクトには好きなように名前を付けることができますが、通常は、どのプロジェクトがテストされているかを明確にする必要があります。プロジェクトの組織については、以前の回答を参照してください。
プライベート、保護、および内部メソッドをテストする必要がありますか、それともパブリックにアクセスできるものだけをテストする必要がありますか?
ここでも、テスト対象のオブジェクトのサード パーティ コンシューマーであるかのように、テストで期待される動作をアサートする必要があります。内部実装の詳細をテストすると、テストが脆弱になります。既存の機能を壊すことを心配することなく、テストで自由にリファクタリングできるようにしたいと考えています。テストが実装の詳細を知っている場合、それらの詳細が変更された場合はテストを変更する必要があります。
単体テストと統合テストは分離する必要がありますか?
はい、単体テストは受け入れテストと統合テストから分離する必要があります。関心の分離は、テストにも適用されます。
100% のテスト カバレッジが得られない正当な理由はありますか?
100% のコード カバレッジにこだわる必要はありません。100% のコード カバレッジは、テストである程度の品質を意味する傾向がありますが、それは神話です。最悪のテストを行っても、100% のカバレッジを得ることができます。代わりに、優れたテスト ファーストのメンタリティに頼ります。コード行を記述する前に必ずテストを記述すれば、100% のカバレッジが保証されるため、議論の余地があります。
一般に、クラスの動作範囲全体を説明することに集中すれば、何も心配する必要はありません。コード カバレッジを指標にすれば、怠け者のプログラマーは単にその目標を達成するだけのことをするだけで、テストの質が低下することになります。代わりに、テストもレビューされるピア レビューに大きく依存します。
Joshの答えは正しいです-明確化の1つのポイントだけです：
単体テストを統合テストと受け入れテストから分離する理由は、速度です。私はTDDを使用しています。作成/変更したばかりのコード行について、ほぼ瞬時にフィードバックする必要があります。統合テストや受け入れテストの完全なスイートを実行している場合、それを取得することはできません。実際のディスク、実際のネットワーク、および非常に低速で予測不可能な外部システムを対象とするテストです。
梁を渡らないでください。そうすると悪いことが起こります。
いい質問です。私たちは有機的に成長しましたが、最善の方法はまさにそれだと思います。ちょっと「場合による…」というのがあります。
「UnitTes」と呼ばれるサブ名前空間で、同じプロジェクトにテストを配置します
私たちのテストクラスはロジッククラスを反映しており、テスト対象に関連してテストがどこにあるかを簡単に追跡できます。
クラスは、テストしているロジック クラスのように名前が付けられ、メソッドは、テストしているシナリオに基づいて名前が付けられます。
public メソッドと internal メソッドのテストのみを作成し (テストは同じプロジェクト内にあります)、クラスの 95% のカバレッジを目指します。
私は「ユニット」と「統合」を区別したくありません。どれがどれであるかを把握しようとすると、非常に多くの時間が費やされます...そのバッグ! テストはテストです。
常に 100% を達成するのは難しすぎます。95%を目指します。また、最後の 5% を取得するのにかかる時間と、実際に何を取得できるかについても、収穫逓減があります。
それが私たちであり、環境とペースに合ったものです。あなたの走行距離は異なる場合があります。あなたの環境と関係している人格について考えてください。
他の人がこれについて何を言っているかを見るのを楽しみにしています！
テストはアプリケーションロジックと同じプロジェクトに含める必要がありますか？
場合によります。どちらの方法でもトレードオフがあります。
1つのプロジェクトに保持するには、プロジェクトを分散するための追加の帯域幅、追加のビルド時間、およびインストールフットプリントが必要になり、テストコードに依存する本番ロジックの間違いを犯しやすくなります。
一方、プロジェクトを個別に保持すると、プライベートメソッド/クラス（プログラミング言語によって異なります）を含むテストを作成するのが難しくなり、新しい開発環境のセットアップ（新しい開発者が参加する場合など）などの管理上の小さな問題が発生します。プロジェクト）難しい。
これらのさまざまなコストがどれほど重要かはプロジェクトによって異なるため、普遍的な答えはありません。
ロジッククラスをミラーリングするためのテストクラスを用意する必要がありますか、それとも必要と思われる数のテストクラスだけを用意する必要がありますか？
いいえ。
十分に因数分解されたテストコード（つまり、最小限の重複、明確な意図など）を可能にするテストクラスが必要です。
テストクラスのロジッククラスを直接ミラーリングすることの明らかな利点は、特定のコードに対応するテストを簡単に見つけることができることです。テストコードの柔軟性を制限せずにこの問題を解決する方法は他にもあります。通常、テストモジュールとクラスの単純な命名規則で十分です。
テストクラス、メソッド、およびプロジェクトにどのように名前を付ける必要がありますか（異なるプロジェクトにある場合）
次のように名前を付ける必要があります。
プライベートメソッド、保護メソッド、および内部メソッドをテストする必要がありますか、それとも公的にアクセス可能なメソッドだけをテストする必要がありますか？
多くの場合、非公開のメソッドをテストする必要があります。パブリックインターフェイスをテストするだけで十分な自信が得られるかどうか、または本当にテストしたいユニットがパブリックにアクセスできないかどうかによって異なります。
ユニットテストと統合テストを分離する必要がありますか？
これは、テストフレームワークの選択によって異なります。テストフレームワークで最適に機能する方を実行し、次のようにします。
100％のテストカバレッジを持たない正当な理由はありますか？
はい、正当な理由があります。厳密に言えば、「100％のテストカバレッジ」とは、コード内で起こりうるすべての状況が実行され、テストされることを意味します。これは、ほとんどすべてのプロジェクトで達成するのは単純に非現実的です。
単に「100％テストカバレッジ」とは、ソースコードのすべての行がテストスイートによってある時点で実行されることを意味する場合、これは良い目標ですが、厄介な場所に数行しかない場合もあります。自動テストで到達する。機能を定期的に手動で検証するコストが、ゆがみを経て最後の5行に到達するコストよりも少ない場合は、100％の回線カバレッジがないのは十分な理由です。
100％のラインカバレッジが必要であるという単純なルールではなく、開発者にテストのギャップを発見し、「カバーされた」ラインの数が改善されるかどうかにかかわらず、それらのギャップを修正する方法を見つけるように促します。つまり、カバーされたラインを測定すると、ラインカバーが向上しますが、実際に必要なのは品質の向上です。したがって、ラインカバレッジは品質の非常に大まかな概算にすぎないことを忘れないでください。
順番に：
あなたの最後の質問に関して、私の経験では、100% のテスト カバレッジを主張しない「正当な」理由は、特に大規模なコード ベースでは、最後の数パーセンテージ ポイントを取得するのに不釣り合いな量の労力がかかるためです。そのため、収益が減少するポイントに到達したら、時間をかける価値があるかどうかを判断する必要があります.