単体テストのガイドライン

StackOverflow https://stackoverflow.com/questions/106800

  •  01-07-2019
  •  | 
  •  

質問

単体テストのガイドラインと推奨事項をどこで見つけられるか知っている人はいますか?次のタイプのトピックに対処するものを用意したいと考えています (たとえば)。

  • テストはアプリケーション ロジックと同じプロジェクト内にある必要がありますか?
  • ロジック クラスをミラーリングするテスト クラスを作成する必要がありますか、それとも必要と思われる数だけテスト クラスを作成する必要がありますか?
  • テスト クラス、メソッド、プロジェクトに名前を付けるにはどうすればよいですか (別のプロジェクトに含める場合)
  • プライベート、保護された内部メソッドをテストする必要がありますか、それとも公的にアクセス可能なメソッドだけをテストする必要がありますか?
  • 単体テストと統合テストは分離する必要がありますか?
  • ありますか 良い テストカバレッジが 100% ではない理由は何ですか?

私がそうあるべきだと、何を求めていないのでしょうか？

オンラインのリソースが最適です。

役に立ちましたか？

解決

私がお勧めします ケント・ベックス TDDに関する本。

また、次の場所に行く必要があります。 マーティン・ファウラーの サイト。テストに関する有益な情報もたくさん持っています。

私たちは TDD にかなり熱心に取り組んでいますので、その観点から質問に答えます。

テストはアプリケーション ロジックと同じプロジェクト内にある必要がありますか?

通常、テストは同じソリューション内に保持しますが、テストをテスト対象の DLL またはプロジェクトをミラーリングする別個の DLL またはプロジェクトに分割しますが、テストがサブ名前空間内にある名前空間を維持します。例：共通 / 共通.テスト

ロジック クラスをミラーリングするテスト クラスを作成する必要がありますか、それとも必要と思われる数だけテスト クラスを作成する必要がありますか?

はい、テストはクラスが作成される前に作成する必要があり、定義上、単一のユニットを分離してテストする必要があります。したがって、ソリューション内のクラスごとにテスト クラスが必要です。

テスト クラス、メソッド、プロジェクトに名前を付けるにはどうすればよいですか (別のプロジェクトに含める場合)

私は動作がテストされるものであることを強調したいので、通常は SUT にちなんでテスト クラスに名前を付けます。たとえば、User クラスがある場合、テスト クラスに次のような名前を付けます。

public class UserBehavior

メソッドには、予想される動作を説明する名前を付ける必要があります。

public void ShouldBeAbleToSetUserFirstName()

プロジェクトには任意の名前を付けることができますが、通常は、どのプロジェクトがテストされているかが明確になるようにする必要があります。プロジェクトの組織に関する以前の回答を参照してください。

プライベート、保護された内部メソッドをテストする必要がありますか、それとも公的にアクセス可能なメソッドだけをテストする必要がありますか?

ここでも、テスト対象のオブジェクトのサードパーティのコンシューマーであるかのように、テストで予期される動作をアサートする必要があります。内部実装の詳細をテストすると、テストは脆弱になります。既存の機能を壊すことを心配せずに、テストで自由にリファクタリングできるようにしたいと考えています。テストで実装の詳細がわかっている場合、その詳細が変更された場合はテストを変更する必要があります。

単体テストと統合テストは分離する必要がありますか?

はい、単体テストは受け入れテストや統合テストから分離する必要があります。関心の分離はテストにも当てはまります。

テストカバレッジが 100% でな​​い正当な理由はありますか?

コード カバレッジ 100% にこだわるつもりはありません。コード カバレッジ 100% は、テストである程度の品質があることを意味する傾向がありますが、それは誤解です。ひどいテストを受けても、100% のカバー率が得られる場合もあります。代わりに、私は正しいテストファーストの精神に頼ろうと思います。コード行を記述する前に常にテストを作成すると、100% のカバレッジが保証されるため、議論の余地はなくなります。

一般に、クラスの動作範囲全体を記述することに集中すれば、何も心配する必要はありません。コードカバレッジを指標にすると、怠惰なプログラマは単にその基準を満たすだけのことをするだけになり、依然として質の悪いテストが残ることになります。代わりに、テストもレビューされるピアレビューに大きく依存します。

他のヒント

良い質問ですね。私たちは有機的に独自に栽培しましたが、それが最善の方法だと思います。そこには「それは場合による...」という部分があります。

同じプロジェクトの「UnitTes」というサブ名前空間にテストを作成しました。

私たちのテスト クラスはロジック クラスを反映しており、テスト対象との関連でテストがどこにあるかを簡単に追跡できます。

クラスにはテスト対象のロジック クラスに似た名前が付けられ、メソッドにはテスト対象のシナリオに応じた名前が付けられます。

パブリック メソッドと内部メソッドのテストのみを作成し (テストは同じプロジェクト内にあります)、クラスの 95% カバレッジを目指します。

私は「ユニット」と「インターゲーション」を区別したくないのです。どれがどれだ...そのバッグを理解するのに非常に多くの時間が費やされるでしょう。テストはテストです。

100% を常に達成するのは非常に困難です。95％を目指します。また、最後の 5% を獲得するまでにどれくらいの時間がかかるか、そして実際に何を捕まえられるかについても、利益は減少しています。

それが私たちであり、環境とペースに適したものです。マイレージは異なる場合があります。自分の環境とそれに関わる人々について考えてみましょう。

この件について他の人が何を言うか楽しみです!

Josh の答えはまさにそのとおりです - 1 点だけ説明します。

私が単体テストを統合テストや受け入れテストから分離する理由は速度です。TDDを使用しています。作成/変更したばかりのコード行について、ほぼ即時にフィードバックが必要です。統合テストや受け入れテストの完全なスイートを実行している場合、つまり実際のディスク、実際のネットワーク、および非常に遅く予測不可能な外部システムを対象とするテストを実行している場合は、この結果を得ることができません。

梁を渡らないでください。そうすると悪いことが起こります。

ぜひ一読をお勧めします テスト駆動開発:例による そして テスト駆動開発:実践的なガイド 単一のトピックに対して質問が多すぎます

最後の質問に関して、私の経験では、100% のテスト カバレッジに固執しない「良い」理由は、特に大規模なコード ベースでは、最後の数パーセント ポイントを取得するのに不相応な量の努力が必要になるからです。したがって、収益が逓減する点に達したら、時間を費やす価値があるかどうかを判断する必要があります。

順番に：

  • いいえ、通常は別のプロジェクトに含めるのが最善です。ただし、実行時に診断を実行できるようにしたい場合は除きます。
  • 理想は 100% のコード カバレッジです。これは、すべてのクラスのすべてのルーチンのすべてのコード行を意味します。
  • 私は、ClassnameTest、ClassnameTest.MethodNameTestnumber を使用します。
  • すべて。
  • 単体テストが失敗した場合、統合テストを実行する必要はないので、「はい」と言えます。
  • フィールドを設定および取得するだけの単純なプロパティはテストする必要はありません。

テストはアプリケーション ロジックと同じプロジェクト内にある必要がありますか?

場合によります。どちらの方法でもトレードオフがあります。

これを 1 つのプロジェクトに保持すると、プロジェクトを配布するために追加の帯域幅が必要になり、追加のビルド時間が必要になり、インストールのフットプリントが増加します。また、テスト コードに依存する実稼働ロジックを使用するという間違いを犯しやすくなります。

一方で、別のプロジェクトを保持すると、プライベート メソッド/クラス (プログラミング言語によって異なります) を含むテストの作成が困難になる可能性があり、新しい開発環境 (例:新しい開発者がプロ​​ジェクトに参加すると) より困難になります。

これらのさまざまなコストがどの程度重要であるかはプロジェクトによって異なるため、普遍的な答えはありません。

ロジック クラスをミラーリングするテスト クラスを作成する必要がありますか、それとも必要と思われる数だけテスト クラスを作成する必要がありますか?

いいえ。

適切に要素化されたテスト コードを許可するテスト クラスが必要です (つまり、最小限の重複、明確な意図など）。

テスト クラスでロジック クラスを直接ミラーリングすることの明白な利点は、コードの特定の部分に対応するテストを簡単に見つけられることです。テスト コードの柔軟性を制限せずにこの問題を解決する他の方法があります。通常は、テスト モジュールとクラスの単純な命名規則で十分です。

テスト クラス、メソッド、プロジェクトに名前を付けるにはどうすればよいですか (別のプロジェクトに含める場合)

次のように名前を付ける必要があります。

  • 各テストクラスとテストメソッドには明確な目的があり、
  • これにより、特定のテスト (または特定の単元に関するテスト) を探している人が簡単に見つけることができます。

プライベート、保護された内部メソッドをテストする必要がありますか、それとも公的にアクセス可能なメソッドだけをテストする必要がありますか?

多くの場合、非パブリックメソッドをテストする必要があります。それは、パブリック インターフェイスをテストするだけで十分な自信が得られるかどうか、または実際にテストしたいユニットがパブリックにアクセスできないかどうかによって異なります。

単体テストと統合テストは分離する必要がありますか?

これは、テスト フレームワークの選択によって異なります。テスト フレームワークで最適に機能するものを実行し、次のことを実現します。

  • コード部分に関連する単体テストと統合テストの両方を簡単に見つけることができます。
  • 単体テストだけを実行するのは簡単ですが、
  • 統合テストだけを実行するのは簡単ですが、
  • すべてのテストを実行するのは簡単です。

テストカバレッジが 100% でな​​い正当な理由はありますか?

はい、それには十分な理由があります。厳密に言えば、「100% のテスト カバレッジ」とは、コード内で考えられるすべての状況が実行され、テストされることを意味します。これは、ほとんどすべてのプロジェクトで達成するのが現実的ではありません。

「100% のテスト カバレッジ」を、ある時点でソース コードのすべての行がテスト スイートによって実行されることを意味すると考えるのであれば、これは良い目標ですが、場合によっては、扱いにくい場所に数行だけ存在することもあります。自動テストで達成します。機能を定期的に手動で検証するコストが、最後の 5 行に到達するまでに苦労するコストよりも低い場合、それは 100% の行カバレッジを実現しない十分な理由になります。

ライン カバレッジを 100% にする必要があるという単純なルールではなく、開発者に次のことを発見するよう奨励します。 どれでも テストのギャップを見つけ、「カバーされた」行数が改善されたかどうかに関係なく、それらのギャップを修正する方法を見つけます。言い換えれば、カバーされるラインを測定すると、ライン カバレッジが向上しますが、実際に必要なのは品質の向上です。したがって、ライン カバレッジは品質の非常に大まかな近似値にすぎないことを忘れないでください。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top