0

私たちの開発では、TDD を使用しているため、次のようなテストがいくつかあります。

"User" should {
  "return 'Mike' if its name is 'Mike'" in {
      val user = User("Mike")
      user.getName === "Mike"
  }
  "return 20 if its age is 20" in {
    val user = User(age = Some(20))
    user.getAge === Some(20)
  }
}

ここで書いているテストは「単体テスト」のようなものです。

次に、specs2 が、より表現しやすい別の種類の構文を提供していることがわかりました。これに興味があります。

def is = s2"""
   User can have name and age, and we have ways to get them, say, if we have a user whose name is "Mike" and the age is "20",
     - we can the name "Mike" [$e1]
     - also can get the age 20 [$e2]
"""
def e1 = {
  val user = User("Mike")
  user.getName === "Mike"
}
def e2 = {
  val user = User(age = Some(20))
  user.getAge === Some(20)
}

TDDで試してみたいのですが、すぐにこの種のテストは「受け入れ仕様」であることがわかりました。私の頭に浮かんだ強い質問があります：

「TDD」と言うと、どのようなテストですか? それらは「単体テスト」でなければなりませんか？「受け入れ仕様」を使用して実装を推進することは良い習慣ですか?

4

3 に答える 3

1

specs2 では、「受け入れ」と「ユニット」という用語は、アクティビティではなく「スタイル」について言及していることを明確にしたいと思います。

私が「承認仕様書」という名前を付けたのは、開発者ではない人でも簡単に読める (つまり、コードが多すぎない) 「承認」文書に共通するスタイルで自分自身を表現できるようにするためです。

一方、「ユニット仕様」は、ユニットテストを書く人にとってより身近なスタイルで表現されています。

しかし、私はこの宗派が規範的であるとはまったく考えていません。好みのスタイルを自由に選択できます。私は単体テストに「受け入れ」スタイルをよく使用します。

于 2014-10-17T22:45:41.733 に答える
1

TDD では、「単体テスト」と他の種類のテストの特定の定義が厳密に必要だとは思いません。特定の種類のテストは、実装の詳細にすぎません。TDD が焦点を当てているのは、開発作業に迅速なフィードバックを提供するために、これらのテストの再現性です。TDD は、それらがどのような種類のテストであるかを必ずしも気にする必要はありません。それらのテストを使用してシステムの開発を推進することだけを気にします。

そのために、(赤/緑/リファクタリング サイクルの一部として) 迅速かつ繰り返し実行できるテストは、TDD スタイルで開発を進めることができます。

手動の QA 部門全体が何らかの形で一時的なフィールドに閉じ込められ、外部のオブザーバーに対して 1 秒の間に何時間もの手動テストを実行できる別の世界を想像できる場合、それらの手動テストは次のように使用できます。これらの外部オブザーバーに対する TDD テスト。(コードカバレッジを測定するのは難しいでしょうが...)

迅速に実行できる反復可能なテストの完全なセットは、TDD に使用できます。

于 2014-10-17T15:04:01.987 に答える
1

TDD は、テストの種類について規範的ではありません。テストを作成して指定/探索し、回帰ハーネスとして使用します。したがって、作業単位を指定する必要がある場合は、おそらく単体テストを作成します。また、システム全体を指定する必要がある場合は、おそらく単体テストとは呼ばないシステムの外部にテストを記述します。

「ユニット」という用語は、実際にはあなたの視点に依存していることに注意してください。多くのコードが実行される場合でも、機能単位を記述するテストを単体テストと見なすことができます。

于 2014-10-17T18:38:58.810 に答える