2

OK、ユニットテストが何であるかは知っていますが、一部のプロジェクトで使用し、他のプロジェクトでは使用していません...一部のクライアントは、それがどのように行われたかを知らず、1つの規則に従っています...何とか何とか。

だからここで私は尋ねています、ユニットテストプロセスはどのように正確に作成されますか? 最初にテストを作成し、次に機能を作成し、その機能のテストを作成し、コードカバレッジを使用して、カバーされていないそのコードのテストがないという「スリップ」を特定することを聞いて読みました。

それでは、簡単な例を使用しましょう。

要件: 「アプリケーションは 2 つの数字を組み合わせた結果を返す必要があります。」

あなたと私は、「Addition」のようなクラスと、次のような整数を返すメソッド「Add」があることを知っています。

public class Addition
{
   public int Add(int num1, int num2)
   {
      return num1 + num2;
   }
}

しかし、このクラスを作成する前でも、最初にテストを作成するにはどうすればよいでしょうか? あなたのプロセスは何ですか？職業はなんですか？その仕様書を入手して開発に入る場合、どのようなプロセスになりますか?

どうもありがとう、

4

1 に答える 1

5

あなたが言及しているプロセスはTest-Driven Developmentと呼ばれます。アイデアはシンプルで、あなたが説明したものに近いです。機能が与えられたら、この機能のテストを書くことからコードを書き始めます。add の例では、動作するコードを作成する前に、簡単なテスト (失敗するテスト) を行う必要があります。

失敗したテスト

[Test]
public void TestAdd()
{
     var testedClass = new Addition();

     var result = testedClass.Add(1, 2);

     Assert.AreEqual(result, 3);
}

これはメソッドの簡単なテストで.Addあり、すぐに機能するコードに対する期待を示しています。あなたはまだコードを持っていないので、このテストは当然失敗します (当然のことですが、これは良いことです)。

合格試験

次のステップは、テストに合格するための最も基本的なコードを書くことです (当然、最も基本的なコードですreturn 3;が、この単純な例では、このレベルの詳細は必要ありません)。

public int Add(int num1, int num2)
{
    return num1 + num2;
}

これは機能し、テストはパスします。この時点で得られたものは、仮定/期待 (テスト) で述べた方法でメソッドが機能するという基本的な証拠です。

ただし、このテストは適切ではないことに気付くかもしれません。多くの単純な入力データのうちの 1 つだけをテストします。言うまでもなく、場合によっては 1 つのテストでは不十分な場合があり、最初の要件があったとしても、さらにテストが必要であることが明らかになる場合があります (引数の検証やロギングなど)。これは、要件の確認とテストの作成に戻るときの部分であり、次のことにつながります...

リファクタリング

この時点で、作成したばかりのコードをリファクタリングする必要があります。そして、単体テスト メソッドのコードとテスト済みの実装の両方について話しています。Addメソッドはかなり単純で、2 つの数値を加算するという点で改善できる点はあまりないため、テストの改善に集中できます。例えば：

  • テスト ケースを追加する (またはデータ駆動型テストを検討する)
  • テスト名をよりわかりやすいものにする
  • 変数の命名を改善する
  • マジックナンバーを定数に抽出する

このような：

[TestCase(0, 0, 0)]
[TestCase(1, 2, 3)]
[TestCase(1, 99, 100)]
public void Add_ReturnsSumOfTwoNumbers(int first, int second, int expectedSum)
{
     var testedClass = new Addition();

     var actualSum = testedClass.Add(first, second);

     Assert.That(actualSum, Is.EqualTo(expectedSum));
}

リファクタリングは 1 冊の本にする価値のあるトピックなので (そしてたくさんあります)、詳細には触れません。ここで行ったプロセスは、多くの場合、Red-Green-Refactor (赤はテストの失敗、緑は合格を示す) と呼ばれ、TDD の一部です。リファクタリングによって誤って何かが壊れていないことを確認するために、もう一度テストを再実行することを忘れないでください。

これが基本的なサイクルの流れです。要件から始めて、失敗するテストを書き、テストに合格するコードを書き、コードとテストの両方をリファクタリングし、要件を確認し、次のタスクに進みます。

ここからどこへ行く？

TDD の背後にある考え方を理解すれば、自然にフォローアップできる有用なリソースはほとんどありません (この投稿で紹介されているような簡単な説明からでも)。

  • 例によるテスト駆動開発- Kent Beck自身による TDD の紹介
  • Test-Driven Development in Microsoft.NET - この本は、特に TDD を初めて使用する場合に最適なウォークスルーです。概念を非常によく説明しており、TDD を使用したアプリケーション開発の包括的な例 (データ アクセス、Web サービスなどを含む) が含まれています。
  • Roy Osherove の TDD Kata - TDD で単純な電卓 API を開発している人々のビデオが含まれています。さまざまな言語、さまざまなフレームワーク (一見の価値あり)
于 2012-04-19T11:42:11.370 に答える