6

私は開発へのBDDアプローチが大好きですが、どこまで進むのかという懸念にぶつかりました。ThoughtWorksの最新のレーダーからのこのコメントは私に一時停止を与えます：

「Cucumberのようなビヘイビア駆動設計（BDD）テストフレームワークの出現と、Seleniumのようなブラウザー自動化ツールの組み合わせにより、ブラウザーレベルでの受け入れテストの広範な使用が促進されました。テストは最高です。代わりに、テストを最大限の効率で実行できるように、コードにできるだけ近い適切なレベルでテストする必要があります。ブラウザレベルのテストは、受け入れとユニットによってサポートされるケーキのアイシングである必要があります。適切なレイヤーで実行されたテスト。」

だからここに私のシナリオがあります（しゃれが意図されています）：

エンドユーザーが選択できる基準に基づいて表示されるデータをフィルタリングするというビジネス要件を備えた基本的なCRUDアプリがあります。説明を簡単にするために、これが電力会社向けのアプリであるとしましょう。各顧客の現在の月ごとの電力使用量を表示しています。このアプリのユーザーは、単一の顧客、複数の顧客、顧客なし、または「すべての顧客」を選択することにより、データを絞り込むことができます。表示されるデータは、選択した内容に基づいて変化します。

製品の利害関係者にとって、これらは実際には4つの別々のシナリオを表しています。ただし、開発者の観点からは、これらは実質的に同一であり、唯一の違いはDBに渡されるパラメーターです。したがって、問題は次のようになります。各順列を詳しく説明することの利点は、それらを実行および維持するコストを上回りますか？

期待される振る舞いの伝達がより明確であるため、BDDの原則はおそらく「はい」と言うだろうと思いますが、私にはわかりません。それは確かに私にはやり過ぎの感覚があります。シナリオは、マイナーな変更を加えた大量のコピー＆ペーストになる可能性があります。

私の傾向は、コアビジネスの価値を捉える単一のシナリオでこの機能をカバーし（「顧客を選択すると電力使用量データが表示される」）、UIベースではない統合テストのセットで他の順列をカバーすることです。サービス/クエリが正しいデータを返すことを検証します。これは間違った考えですか？BDDの利点を放棄することなく、これらのシナリオがカバーされていることを確認するための最良の答えは何ですか？

4

2 に答える 2

4

私のBDDのルールは、開発者は記述されている動作からシナリオを簡単に導き出すことができ、できない場合はシナリオを使用して動作を説明できるようにすることです。

BDDは、トリッキーなことを説明するときに最も役立ちます。専門家の知識を開発者に渡すとき、または不確実性が発見されるまで行動を絞り込むとき。基本的なフィルターを備えたCRUDアプリケーションでは、動作は非常に理解しやすいものです。

あなたが説明していることは、おそらくダンノースの「ジンジャーケーキ」パターンを最もよくカバーしています。レシピを別のものに取りますが、行動のある側面は別の側面とは異なります（またはこの場合、行動の1つの追加のわかりやすい側面があります） ）。彼はまた、コピー＆ペーストを少し使用していますが、特にこの種の動作が疑われます。

だから、あなたの傾向は完全に正しいです。自動化する場合は、おそらく1つの例だけを自動化し、残りはユニットテストと統合テストでカバーします。

また、なぜこのプロジェクトが進められたのか知りたいです。それについて何か面白いことがなければなりません、さもなければそれは起こらないでしょう。それを見つけてください。シナリオについて話し合うのに最適な場所です。

于 2012-09-25T15:12:24.883 に答える
0

シナリオをリファクタリングしている場合、通常は重複するスクリプトから小さなテーブルを抽出することで、メンテナンスコストがまったく問題にならない可能性があります。ただし、これでは実行時間のコストの問題は解決されません。

このような状況では、最も単純なシナリオ（顧客なし）と最も複雑なシナリオ（多くの顧客がフィルターに一致しますが、すべてではありません）の両方を自動化し、他の順列をより焦点を絞ったプログラマーテストに任せることをお勧めします。「顧客がいない」場合は、プログラムがときどきクラッシュする場合のように、人々がそれをひどく間違える傾向があるという理由だけで含めます。（シードデータスクリプトを実行していませんか？！）

于 2012-09-25T16:42:11.333 に答える