0

以前は、メソッドが機能するかどうかをテストするためだけに単体テストを実装していました。しかし、他の場所で読んだ後、メソッドが失敗したときにテストする必要があるようです。

たとえば、メソッドは文字列を渡した例外をスローする必要があります。

これらの要件はどこから来たのですか?

私はアジャイル チームで働いているので、アプリケーションの機能が何をするかという基本的な要件を含むユーザー ストーリーを受け取ります。これらの基本的な要件には、非常に単純な要件が含まれ ます (つまり、パスワードの長さは最大 8 文字である必要があります)。

次に、要件を考慮して、このユーザー ストーリーからタスクを作成します。

したがって、テストするとき...正確には、何をテストする必要がありますか?

メソッド (ユーザー ストーリーの一部であるタスクの一部) が正常に機能することをテストする必要があると思いますが、失敗する必要があるときに失敗することもテストする必要がありますか?

たとえば、要件が最大 8 文字である場合、メソッドのパラメーター (パスワード) に 12 文字を渡します。そのためのテストケースを含める必要がありますか?

この主題についてもう少し説明している優れたリソースまたはリンクを知っている人はいますか?

要件がないと、メソッドが成功するかどうか、および失敗するかどうかのみをテストできると思います。要件がないためにいつ失敗するかがわからないからです。

誰でも提供できるヘルプは本当に役に立ちます。

4

3 に答える 3

1

ハッピー パス テストから始めます。ハッピー パスは、要件のユース ケースに基づいている必要があります。

すべてのハッピー パスをカバーしたら、境界テストに進みます。したがって、パスワードが 8 文字である必要がある場合は、7、8、9 文字のテストを行い、そのシナリオをカバーします。

すべてのハッピー パス テストと境界テストをカバーしたら、失敗するテストをどのように作成できるか自問してみてください。思いついたら書いてみよう。発生させる必要があるのが例外である場合は、それをカバーします。それを念頭に置いて、何をテストする必要があり、何をあまり必要としないかを簡単に把握できます。

于 2012-07-22T20:01:02.293 に答える
1

失敗のテストを読みすぎていると思います。つまり、コードを記述する前にテストを記述します (null のような無効な値を常に返すスタブは別として)。そうすれば、失敗したときに記述するコードがあることがわかります。次に、コードを記述して再度テストします。これでテストに合格するはずです。テスト駆動開発は、常にこのように機能する必要があります。

于 2012-07-22T16:54:43.157 に答える
1

すべての可能性をテストすることはできませんが、少なくともコードで考慮されている可能性をテストする必要があります。

したがって、メソッドに渡される文字列が 8 文字を超えてはならない例では (ちなみに、これはパスワードの厳しい要件です)、メソッドは次のようになります。

public bool IsPasswordCorrect(string password)
{
    if (password.Length > 8)
        throw new ArgumentException("Password must not be greater than 8 characters.");

    return password == SomeKnownPassword;
}

目標は、100% のコード カバレッジにする必要があります。つまり、実際に何かを実行するコードの各行には、少なくとも 1 つの対応するテストが必要です。したがって、唯一のテストが「ハッピー パス」(8 文字以下の文字列) の場合、そのthrow行はテストされません。

そのコード行は要件に対応するものであるため、その要件をテストする必要があります。この場合、いくつかのテストがあります。

[TestMethod]
public void MatchingPasswordsShouldBeAllowed()
{
    // set the known password
    // set the passed password
    // call the method
    // assert that the method returned true
}

[TestMethod]
public void NonMatchingPasswordsShouldNotBeAllowed()
{
    // set the known password
    // set the passed password to something else
    // call the method
    // assert that the method returned false
}

[TestMethod]
[ExpectedException(typeof(ArgumentException))]
public void PasswordsShouldNotBeGreaterThanEightCharacters()
{
    // set the known password
    // set the passed password to something too long
    // call the method
    // assert that an exception was thrown
}

テスト メソッドの名前に注意してください。それらは要件のように聞こえます。この考え方は、規定された要件を実際の仕様に分解する必要があるというものです。ビジネス要件は次のとおりです。

  • パスワードは 8 文字以内にする必要があります

しかし、そこに暗黙の要件はありますか? 次のような要件:

  • 既知のパスワードと一致する提供されたパスワードにより、認証が行われます。
  • 既知のパスワードと一致しない提供されたパスワードは、認証につながるべきではありません。

結局のところ、メソッドはこれらすべてのことを行っています。メソッドが何かを実行している場合は、その何かをテストする必要があります。最終的に、コードが行うすべてのことは、要件に対応する少なくとも 1 つの対応するテストを持つ必要があります。

実際、テストが適切に作成されていれば、要件になり始めます。問題の知識 (要件) を複数の異なる場所 (テスト、コード、ドキュメント、ホワイトボードなど) ではなく 1 つの場所 (テスト) に保持できるため、これは良いことです。

テストによって実行されないコード行がある場合、なぜそのコード行があるのでしょうか? それに対するテストがない場合、それに対する要件はありません。要件がない場合は、削除してください。

于 2012-07-22T17:14:20.747 に答える