行動主導の開発は設計や分析に関するものですか？

Question

BDDについて読んだり、TDDがどのように改善されるべきかを読んだりするほど、混乱しているように見えます。設計に関するものであると言う専門家からの引用を見つけましたが、分析に関すると言う他の専門家からも引用しています。

現在私が見ているのはこれです：

1）分析：BDD

ウィキペディア

から

  

オブジェクト指向分析の結果   システムとは何かの説明です   機能的に必要な、   概念モデルの形式。

したがって、BDDの後には要件（ストーリーとシナリオ）があります。しかし、概念モデルの部分についてはわかりません。

2）設計：たとえば、CRCカードを使用した応答性駆動設計などのツールを使用して

3）コード：デザインをコーディングし、オプションでテストを使用します（TDDが間違っていることについて言うように、私も有用だと思います）

私はこれをどう見るか間違っていますか？現時点では、木々を通して森を見るのに問題があります。

Answer 1

要するに、分析に関することです。

BDDは「受け入れテスト駆動開発」用です。 -つまり、テスト中のシステムが特定のユーザーストーリーシナリオで期待どおりに動作するかどうかを知るため。

Jbehaveで作業したとき、ユーザーストーリーレベルで使用しましたが、それでも「従来型」でした。個々のオブジェクト間およびサブシステム間のコラボレーションを処理するためのTDD。

通常、ビジネスシステムはBDDシナリオを使用して、システム内の小さな実装の詳細をテストしないビジネスドメインの動作を記述します。ドメインエキスパートの抽象化レベルに合わせたBDDシナリオが必要です。これらのシナリオは、ドメインの専門家にはあまり意味がなく、実装の細部をすべて説明していると非常に壊れやすくなります。

BDDのシナリオでは、ユーザーストーリーに対してシステムが行うべきことは何であるかが説明されていますが、その方法はありません。

Answer 2

BDDは、「実行可能な仕様」を記述することです。または受け入れテスト別名ブラックボックステストは、定義により、テストケースを導出するためのテストオブジェクトの外部パースペクティブ。

したがって、BDDは設計に関するものではなく、BDDは機能/ストーリー/シナリオのテストに関するものであり、BDDは分析に近いものです。

Answer 3

BDD-行動駆動開発

Behavior = ..in the context .. 開発-...の構築中...

この場合の開発は、分析が完了し、特定の動作のコンテキストで何かを実装していることを示しています。

質問に答えるために、デザインで信じています。

Answer 4

私は、アーキテクチャーからPOV BDDは設計に関するものだと思います。何かを行うことができるアプリケーションを設計する必要がありますが、それは後に受け入れテストで使用されます。そのため、高レベルの設計から、さまざまな動作要件に合わせて設計していることを確認したいので、過剰な設計を行わず、重複を制限します。

これは、ユーザーが実際に見たいもの、アプリケーションの実行方法について考える時間があるため、再設計する必要がないようにするのに役立ちます。

Answer 5

BDD（またはTDD）は、約ではありません。分析および設計（およびその厄介な小さな実装ステップ）をサポートする手法（BDDの場合、より多くのアプローチ）です。 「赤、緑、リファクタリング」というフレーズをよく耳にします。 TDDに関連付けられているため、BDDに適用されます。テストを作成して失敗することを確認し、コードベースを更新してテストに合格し、合格したテストを保存しながらシステムを改良した形に作り直します。

したがって、BDDはテストの作成時に分析をサポートします。テストまたは例の形式で必要な動作を説明する必要があります。テストを実行するときに設計をサポートします。設計の決定が不必要に必要な動作を壊すことを防ぎ、分析によって導くことができます。ただし、分析や設計は一切行いません。あなたはまだ考えなければなりません。これは、分析と設計のステップで、矛盾しないようにするための方法です。

Answer 6

BDDとTDDには、使用目的が実際にはカバーされていないため、さらに不運な名前が付けられています。

• 開発者が開発サイクル中に可能なすべてのコーナーケースに対してテストを作成する必要はありません。これはテスターが選択する必要があるものです。
• リグレッションは不要であり、反復をクリアするために必要なコードを記述していることを確認したいので、繰り返し可能な結果が必要です
• 最初は詳細な設計を行う必要はありませんが、今回は完成したいいくつかの要件を書き留めてください。

BDD / TDDは、作成しようとしているコードの一部を説明するコードを作成する前にコード行を作成しなければ、2つのうちのどれでも問題ありません。それを行うと、ゾーンに入ります。
BDD / TDDが開発速度を改善するという証拠はありませんが（ほとんどの場合、改善されません）、実証済みのソフトウェアをリリースした後に戻ってくる問題の数を大幅に減らします。

BDDはTDDの進化版であり、TDDはBDDのすべてをテストするように圧力をかけ、内部が変更される可能性があるため、クラスの公開動作のみをテストするように言っています。

BDDは分析と同じくらいデザインに関するものですが、それがあなたの質問だとは思いませんか？ストーリーをフローチャートやアーキテクチャ図に変換する方法を知りたいですか？

私があなたの質問から得たのは、あなたが前もって大きなデザインを作り、それをコーディングしようとするからです。断片的な方法で記述する必要があるストーリーを満足させながら、コードとアーキテクチャを自動的に取得するため、BDDでは機能しません。緊急設計と呼ばれるため、大規模な計画段階はありません。

SCRUMや同様の賢明なシステムでは、ビジネスがストーリーを優先するため、これは非常にうまく機能します。最初から始めて、その仕様/例を記述し、このバックログ項目を完了するまでこれを繰り返す例を満足させてから、次の項目を選択してやり直します。

これがあなたの質問に答えることを望みます。そうでない場合は、それがおかしなトピックなので少し明確にする必要があるでしょう。要するに、BDDは純粋に開発者向けのツールであり、アーキテクトやBA向けではありません...テスターはBDDツールを使用できますが、アプリケーションのテストに使用しているツールはこれだけではないことを願っています。