-1

このサイトを含む Web 上の関連トピックを読んでいます。しかし、問題の主題を説明するためのコードがたくさんあるものを見つけることができません。

私はしばらくの間、TDD と単体テストを実践してきました。クラスレベル、メソッドレベルの観点から、ユニットテストを行うべきものとすべきでないものを見つけたいと思います。たとえば、すべてをテストする必要がありますか (統合テストとは何ですか)。ターゲット メソッド内で、どのコード行を単体テストする必要がありますか? この分野に関する優れた原則や実践、または説明するためのコードサンプルがたくさんある優れた読み物はありますか。

ここでのトピックは、C# や Java などのサーバー側言語に関するものです。

アップデート

以下の本は私が探しているものをカバーしていないことに注意してください（私が正しい場合）

実用的な単体テスト

単体テストの芸術

4

2 に答える 2

4

大まかに言えば、単体テストはホワイト ボックス テストである必要があり、統合テストはブラック ボックス テストである必要があります。

つまり、単体テストはコード単位 (通常はメソッド) の内部動作に依存する必要があります。開発者は、メソッドを介して可能な実行パスを調べ、それぞれのテスト ケースを作成します。単体テストでは、メソッドを分離してテストする必要もあります。テスト対象のメソッドのみが単体テストによって実行されるように、共同作業者または入力と出力をモックする必要があります。

if実行パスを見つけるには、メソッドへの可能な入力と、そこにある分岐 (ステートメントや例外など)について考える必要があります。例えば

public boolean isYes() {
    return someValue.equals("yes");
}

このメソッドにはifステートメントはありませんが、3 つの実行パスがあります。

  • someValueである場合"yes"、メソッドは戻りますtrue
  • 、、、またはそれが返すsomeValueような他の文字列である場合"Yes""no""bananas"""false
  • someValueそれがnullスローされる場合NullPointerException

この場合、これらの実行パスについて考え、それらのケースをカバーする単体テストを作成すると、メソッドにどのような問題があるかを考えるのに役立ちます。

実行パスがコードのいくつかのユニットを訪問するテストは、統合テストになります。全体的な入力と出力に関してテストを実行します。それがどのように機能するかは気にしません。それが機能することだけです。

個人的には、コード ベースに関する独自の知識に基づいて単体テストを作成し、メソッドごとに個別に作成します。要件からの仕様と個々の受け入れ基準に基づいて統合テストを作成します。

于 2013-03-20T12:05:04.107 に答える
0

Pragmatic Unit Testingは Pragamatic シリーズの中で最高のものではありません。数年前に読んだときには、nunit テクニックはかなり軽量で時代遅れでした。しかし、それは十分に安価であり、原則と実践をカバーしています.

Art of Unit Testingも読む価値があります。

乾杯、
ベリル

于 2013-03-20T12:09:02.927 に答える