BDD と、BDD がどのように TDD を改善するかについて読めば読むほど、すべてが混乱しているように思えます。私は、それが設計に関するものであると言う専門家からの引用を見つけましたが、それは分析に関するものであると言う他の専門家からの引用も見つけました.
私が現在見ている方法は次のとおりです。
1) 分析: BDD
ウィキペディアから
オブジェクト指向分析の結果は、システムが機能的に実行する必要があることを概念モデルの形式で記述したものです。
したがって、BDD の後に要件 (ストーリーとシナリオ) があります。しかし、概念モデルの部分についてはよくわかりません。
2) 設計: たとえば、CRC カードを使用した責任駆動型設計などのツールを使用
3) コード: 設計をコーディングし、必要に応じてテストを使用します (TDD が間違っていると彼らが言うように、これも役に立ちます)
私はこれをどう見るか間違っていますか？現在、木々の間から森が見えず困っています。
要するに、それはAnalysisと関係があります。
BDD は「受け入れテスト駆動開発」のためのものです。つまり、テスト中のシステムが特定のユーザー ストーリー シナリオに対して期待どおりに動作するかどうかを知るためのものです。
私が Jbehave を使用したときは、ユーザー ストーリー レベルで使用しましたが、個々のオブジェクト間およびサブシステム間のコラボレーションを処理するために「従来の」TDD を使用していました。
通常、ビジネス システムは BDD シナリオを使用してビジネス ドメインの動作を記述し、システム内の小さな実装の詳細をテストしません。ドメイン エキスパートの抽象化レベルで提案された BDD シナリオが必要です。これらのシナリオは、ドメインの専門家にはあまり意味がなく、実装の細部をすべて説明すると非常に脆弱になります。
BDD シナリオは、システムがユーザー ストーリーに対して何をすべきかを示しますが、それをどのように行うかは示しません。
BDDは、「実行可能仕様」または受け入れテスト、別名ブラックボックステストを作成することを目的としています。これは、定義上、テストオブジェクトの外部の視点を利用してテストケースを導き出します。
したがって、BDDは設計に関するものではなく、BDDは機能/ストーリー/シナリオのテストに関するものであり、BDDは分析に近いものです。
BDD - ビヘイビア駆動開発
動作 = .. のコンテキストで.. 開発 - ... の構築で...
この場合の開発は、分析が完了し、特定の動作のコンテキストで何かを実装していることを示しています。
質問に答えるために、私はそのデザインにあると信じています。
アーキテクチャからPOVBDDはデザインに関するものだと思います。何かを実行できるアプリケーションを設計する必要があります。このアプリケーションは、後で受け入れテストで使用されます。したがって、高レベルの設計から、さまざまな動作要件に合わせて設計していることを確認して、過剰に設計しないようにし、重複を制限したいと思います。
これは、ユーザーが実際に見たいもの、アプリケーションのパフォーマンスについて考える時間が増えるため、再設計する必要がないことを保証するのに役立ちます。
BDD (または TDD) は重要ではありません。これは、分析と設計 (および厄介な小さな実装ステップ)をサポートする手法 (BDD の場合はよりアプローチ)です。TDD に関連する「レッド、グリーン、リファクタリング」というフレーズをよく耳にしますが、これは BDD にも当てはまります。テストを作成して失敗することを確認し、コードベースを更新してテストをパスさせ、システムを改善された形に作り直します。合格したテストを保存します。
そのため、BDD はテストを作成する際の分析をサポートします。テストまたは例の形式で必要な動作を記述する必要があります。テストを実行するときの設計をサポートします。設計上の決定が、必要な動作を不注意で壊すことを防ぎ、分析によって導くことができます。ただし、分析や設計は一切行いません。あなたはまだ考えなければなりません。これは、分析と設計の段階で矛盾しないようにするための方法です。
BDD と TDD は、実際にはそれらが何に使用されるかをカバーしていないため、非常に不運な名前になっています。
BDD/TDD のいずれかを記述しようとしているコードのビットを説明するコードのビットを取得する前に、コード行を記述しない場合は、2 つのいずれでも問題ありません。そうすることでゾーンに入ります。
BDD/TDD が開発速度を改善するという証拠はありませんが (ほとんどの場合改善されません)、ソフトウェアのリリース後に返される問題の数が大幅に減少することが証明されています。
BDD は TDD の進化版であり、TDD はすべてをテストするように圧力をかけます。BDD はこれを緩和し、内部が変更される可能性があるため、クラスのパブリックな動作のみをテストする必要があると述べています。
BDD は分析に関するものと同じくらい設計に関するものですが、それはあなたの質問ではないと思いますか? ストーリーをフローチャートやアーキテクチャ図に変換する方法を知りたいですか?
あなたの質問から私が得たのは、あなたが前もって大きなデザインを作り、それをコード化しようとしているということです. それは BDD では機能しません。なぜなら、少しずつ書く必要があるストーリーを満足させながら、コードとアーキテクチャを自動的に取得するからです。これは緊急設計と呼ばれるため、大規模な計画フェーズはありません。
スクラムや同様の賢明なシステムでは、ビジネスはあなたのストーリーを優先するため、これは非常にうまく機能します。一番上から始めて、その仕様/例を書き、このバックログ項目を完了するまでこれを繰り返し、例を満たすようにしてから、次のものを拾い上げて最初からやり直します。
これがあなたの質問に答えてくれることを願っています.. そうでない場合は、それが難しいトピックであるため、少し明確にする必要があります. 要するに、BDD は純粋に開発者ツールであり、アーキテクトや BA 向けではありません... テスターは BDD ツールを使用するかもしれませんが、アプリケーションのテストに使用するツールがそれだけではないことを願っています。