6

テストベースの開発は初めてなので、この質問は私を悩ませてきました。多すぎるとはどのくらいですか？何をテストし、どのようにテストし、なぜテストする必要があるのか​​? 与えられた例は NUnit を使用した C# のものですが、質問自体は言語に依存しないと思います。

これは私自身の現在の2つの例であり、一般的なリストオブジェクトのテストです（文字列でテストされ、初期化関数は3つのアイテムを追加します{"Foo", "Bar", "Baz"}）：

[Test]
public void CountChanging()
{
    Assert.That(_list.Count, Is.EqualTo(3));
    _list.Add("Qux");
    Assert.That(_list.Count, Is.EqualTo(4));
    _list[7] = "Quuuux";
    Assert.That(_list.Count, Is.EqualTo(8));
    _list.Remove("Quuuux");
    Assert.That(_list.Count, Is.EqualTo(7));
}

[Test]
public void ContainsItem()
{
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false));
    _list.Add("Qux");
    Assert.That(_list.Contains("Qux"), Is.EqualTo(true));
    _list.Remove("Qux");
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false));
}

コードはかなり自己コメントなので、何が起こっているのかについては触れませんが、この種のことはやりすぎですか? Add()もちろん、Remove()個別にテストされるので、これらの種類のテストではどのレベルに行く必要がありますか? 私はこれらの種類のテストを受ける必要がありますか？

4

4 に答える 4

7

あなたが実際にテストしているのは等価クラスだと思います。私の見解では、アイテムが 3 つまたは 7 つのリストに追加することに違いはありません。ただし、0 個のアイテム、1 個のアイテム、および 1 個以上のアイテムには違いがあります。最初は、これらのケースの Add/Remove メソッドごとに 3 つのテストを行うことになるでしょう。

QA/ユーザーからバグが入り始めたら、そのようなバグ レポートをそれぞれテスト ケースとして追加します。赤いバーを取得して、バグの再現を確認します。緑色のバーを取得してバグを修正します。このような「バグ検出」テストはすべて残っています。これは私のセーフティ ネット (回帰テストと読みます) であり、この間違いを再び犯した場合でも、すぐにフィードバックを得ることができます。

于 2008-10-04T07:37:29.840 に答える
6

テストを仕様と考えてください。テストが失敗することなくシステムが壊れる (または重大なバグがある) 場合、十分なテスト範囲がありません。単一障害点が原因で多くのテストが中断する場合は、テストが多すぎる (または結合が強すぎる) 可能性があります。

これを客観的に定義するのは非常に困難です。私は、あまりにも多くのテストの側でエラーを言うと思います. 次に、テストが煩わしくなり始めると、それらはリファクタリング/再目的化する特定のテストです (脆弱すぎるか、間違ったことをテストし、失敗が役に立たないため)。

于 2008-10-04T06:57:16.643 に答える
2

いくつかのヒント:

  1. 各テストケースは、1 つのことだけをテストする必要があります。つまり、テストケースの構造は「セットアップ」、「実行」、「アサート」でなければなりません。あなたの例では、これらのフェーズを混在させます。テストメソッドを分割してみてください。これにより、何をテストしているのかを正確に確認しやすくなります。

  2. テストメソッドに、テスト対象を説明する名前を付けてみてください。つまり、ContainsItem() に含まれる 3 つのテストケースは次のようになります。実際のテストをコーディングする前に、テストする必要があるものを概念化するのに、このようなわかりやすい名前を思いつくように強制することがわかりました。

  3. TDD を行う場合は、最初にテストを記述し、失敗したテストがある場合にのみ実装にコードを追加する必要があります。実際にこれを行わなくても、何回のテストで十分かがわかります。または、カバレッジ ツールを使用します。コンテナーのような単純なクラスの場合、100% のカバレッジを目指す必要があります。

于 2008-10-04T07:05:14.897 に答える
1

_listあなたが書いたクラスのインスタンスですか？もしそうなら、それをテストすることは合理的だと思います。その場合、なぜカスタム List クラスを作成するのですか?

あなたが書いたコードでない場合は、何らかのバグがあると思われる場合を除き、テストしないでください。

独立したモジュール式のコードをテストしようとしています。私が維持しなければならないコードにある種の神の機能がある場合、私はそれを可能な限りサブ機能に取り除き、それらを独立してテストします。次に、神の関数は「明らかに正しい」ように記述できます。分岐もロジックもなく、よくテストされたサブ関数から別のサブ関数に結果を渡すだけです。

于 2008-10-04T06:56:33.323 に答える