1

非常に単純な BDD の例を示している Luke Redpath による古い記事を偶然見つけました(非常に短く、私のような Ruby 以外のプログラマーでも簡単に理解できます)。最終結果は非常に不完全であることがわかりました。そのため、この例はほとんど役に立ちません。

最終結果は、事前設定された属性を持つユーザーが有効であることを検証する単一のテストです。私の見解では、これは検証ルールを正しく検証するのに十分ではありません。たとえば、

validates_length_of :password, :in => 6..12, :allow_nil => :true

に

validates_length_of :password, :in => 7..8, :allow_nil => :true

（またはパスワードの長さの検証を完全に削除することさえできます）テストは引き続きパスしますが、コードが初期要件に違反していることは明らかです。

個々のテストをすべて 1 つのテストにまとめるという最後のリファクタリングだけでは十分ではないと思います。彼は、あまり保証されていない「ハッピー パス」のみをテストします。特定の値で正しいエラーがトリガーされることを確認するすべてのテストが絶対に必要です。パスワードの場合、長さが 6 未満で 12 を超えるパスワードが無効であり、適切なエラーがトリガーされることをテストします。「ハッピー パス」テストも同様に存在しますが、記事にあるようにそれだけではありません。

あなたの意見は何ですか？私はただ、その男がなぜ彼のやり方でそれをしたのか、そして彼が単に問題を見落としていたのか、それとも彼の意図だったのかを理解しようとしています. 私は何かが欠けているかもしれません。

4

3 に答える 3

1

私はあなたの質問をよく理解していません。仕様には、ハッピーパスと2つの異なる障害モード（パスワードが長すぎるとパスワードが短すぎる）の両方について、パスワードの長さに関する期待が含まれています。

specify "should be valid with a full set of valid attributes" do
  @user.attributes = valid_user_attributes
  @user.should_be_valid
end

valid_user_attributes有効なパスワードが含まれているため、これによりハッピーパスが処理されます。

specify "should be invalid if password is not between 6 and 12 characters in length" do
  @user.attributes = valid_user_attributes.except(:password)
  @user.password = 'abcdefghijklm'
  @user.should_not_be_valid
  @user.password = 'abcde'
  @user.should_not_be_valid
end

そして、これは2つの故障モードをテストします。

確かに、1つの境界ケースが欠落しています（12文字）が、それはそれほど悪くはありません。

于 2009-12-21T23:58:04.403 に答える
0

記事を読む時間がないので、あなたの主張を検証することはできませんが、私の意見では、パスワード検証ルールが具体的な要件である場合は、1つ以上のテストで検証する必要があります特定の要件（要件の「一部」ごとに少なくとも1つ）。

于 2009-12-21T13:14:50.787 に答える
0

BDD (および TDD) は設計活動です。テストは、コードの設計を促進するためのものであり、完全にバグがないことを保証するものではありません。そのための独立したテスターが必要です。そのため、コードが期待どおりに機能し、例外をクリーンな方法で処理できるようにするために、適切な範囲のカバレッジが必要です。しかし、TDD では、考えられるすべてのエッジ ケースに対して単体テストを作成する必要はありません。

あなたが引用した特定の例に関しては、おそらく彼は 2 つのテストをコーディングする必要がありました.1 つは 6 文字のパスワードで、もう 1 つは 12 文字のパスワードです。しかし、ポイントは何でしょうか？パスワードの長さは 6 ～ 12 文字である必要があることがわかっています。要件を誤解していて、ルールは…

validates_length_of :password, :in => 7..8, :allow_nil => :true

...次に、テスト データを記述して、誤った解釈に合格するテストを作成します。したがって、より多くのテストを作成しても、見当違いの自信しか得られません。そのため、TDD と BDD の支持者は、ペア プログラミングなどの他の XP 手法も好んで使用します。これは、単体テストに導入されたエラーを検出するためです。

同様に、パスワードの長さを検証するテストを完全に削除することもできますが、ポイントは何でしょうか? テストは、仕様を正しく実装するのに役立ちます。私たちが書いたコードのすべての部分に対してテストがなければ、TDD/BDD を行っていません。

于 2009-12-21T13:43:11.913 に答える