c# - テストケースの書き方は？

Question

コードを書く前に、テストケースの書き方を学びたいです。テスト駆動開発に関する記事を読みました。開発者はどのようにテストケースを書くのだろうか？たとえば、このメソッド：

    public int divideNumbers(int num1, int num2)
    {
      return num1 / num2;
    }

score 4 · Accepted Answer

空のプロジェクトから始めます。何かをしたいとします。たとえば、2 つの数値を割ります。したがって、何をしたいのかを説明するテストを作成します。

Assert.That(divide(10,2), Eq(5))

このテストはエントリポイントを提供します。つまり、divideメソッドの受け入れ可能なインターフェイスを記述します。したがって、例として実装に進みますint divide(int x, int y)。

コードから得られると期待される内容を説明するテストを作成します。あまり考える必要はありません。期待値を記述する最も一般的な方法は、おそらくコードを設計するための最良の方法であり、それを実装してテストを満足させることができます。

score 1 · Accepted Answer

テストにはいくつかの手順があります。からMSDN;

あなたの場合;

Assert.AreEqual(divideNumbers(8, 4), 2);

Asserttrueクラスは/false命題を使用して単体テストで条件を検証します。結果を期待するようにテストケースを作成する必要があります。TestMethodテストメソッドに属性を使用できます。C# コードの単体テストの作成に関するクールな投稿があります。よく分析してください。

score 1 · Accepted Answer

開発したい関数/クラス/コンポーネントのスタブから始めます。コンパイルする必要がありますが、意図的に（まだ）実行しないでください。

例えば：

public int divideNumbers(int num1, int num2)
{
    throw new NotImplementedException();
}

また

    return -42;

スタブをブラックボックスへのインターフェイスとして扱い、意図した動作について考えます。実装については (まだ) 気にしないでください。インターフェイスの「コントラクト」について考えてみましょう。X が入り、Y が出ます。

標準的なケースと重要なエッジのケースを識別します。それらのテストを作成します。

整数の除算については (最初から書くと仮定して)、考慮すべきケースが実際にはかなりあります: 剰余がある場合とない場合、n/1、n/0、0/n、0/0、負の数などです。

Assert.IsTrue(divideNumbers(4,4) == 1);
Assert.IsTrue(divideNumbers(4,3) == 1);
Assert.IsTrue(divideNumbers(4,2) == 2);
Assert.IsTrue(divideNumbers(4,1) == 4);
Assert.Throws<ArgumentException>(() => divideNumbers(4,0));

Assert.IsTrue(divideNumbers(0,4) == 0);
Assert.Throws<ArgumentException>(() => divideNumbers(0,0));

Assert.IsTrue(divideNumbers( 4,-2) == -2);
Assert.IsTrue(divideNumbers(-4, 2) == -2);
Assert.IsTrue(divideNumbers(-4,-2) ==  2);

Assert.IsTrue(divideNumbers( 4,-3) == -1);
Assert.IsTrue(divideNumbers(-4, 3) == -1);
Assert.IsTrue(divideNumbers(-4,-3) ==  1);

単体テストをコンパイルして実行します。それらはすべて失敗しますか？そうでない場合、なぜですか？テストの 1 つが意図したとおりに機能していない可能性があります (テストにもバグがある可能性があります!)。

ここで、テストが失敗しなくなるまで実装を開始します。

score 0 · Accepted Answer

理論と実践の違いを理解することから始めましょう。

実際のシステムには、TDD を介して簡単に作成できるものとそうでないものがあります。

最後のグループは、環境の仮定を抽象化しようとせず、実用的に受け入れるシステムで作業する場合、すべてが環境に依存するものです。

このグループは TDD 方式で開発できますが、追加のツールとソフトウェアファクトリへの拡張が必要になります。

.Net の場合、これは MS 仮想テストラボや SpecFlow などのツールと拡張機能になります。

私が伝えようとしているのは、それが依存しているということです。

非常に単純なコンポーネント/ユニットテストの場合、テスト対象のコードを記述する前に失敗するテストケースを記述し、テストが正常に実行されたら開発を終了するという考えになります。

統合テストとそれ以降 (システムテスト) では、何をテストするかを検討することに加えて、テスト環境を既知の状態にする方法などを考慮する必要があります。

c# - テストケースの書き方は？

4 に答える 4

Related

Reference