BDDは中規模から大規模のプロジェクトに拡張可能ですか？
BDD（Behaviour Driven Development）について読んだすべてのWebサイトで、要件を定義することがいかに明白で簡単であるかを示す非常にシンプルな素晴らしい例を見つけます。しかし、このプロセスを（電卓の例ではなく）大きな製品に実装しようとすると、物事がかなり複雑になり、判読できなくなる可能性があることがわかりました。特に後からリクエストを変更すると、統合テストを修正するために多くの作業が必要になります。
BDDは本当に価値があるのでしょうか。他のテクニックでは解決できない問題を解決しますか？
[〜＃〜] bdd [〜＃〜]の最高のリソースの1つは です例 本。これは、BDDテストを整理する方法と、要件が変更されたときにそれほどやり直さないようにそれらを記述する方法について多くを説明しています。
テストで物事が複雑になったり、過度に複雑になったりした場合は、おそらく何かが間違っています。 BDD、TDDも同様です。良いテストを書くのは難しく、それを学ぶのに何ヶ月もかかります。
BDDの焦点は会話であることを理解するのに役立つかもしれません。 BDDは本当に分析ツールで、ニースの副産物として回帰テストを提供します。
私は会話のあらゆる種類のレベルでシナリオを使用しました。 さまざまな利害関係者の特定から リリースが受け入れられる可能性があるかどうかを確認するために、 モジュールまたはクラスの動作を理解する 。
これを簡単にするためのヒントとヒントがいくつかあります。
これまでに行ったことがない場合は、変更されます
ドメインまたはビジネスにとって新しいものはすべて変更される可能性があります。シナリオを通して話していると、この領域にいることに気付くかもしれません それらを質問する 、そしてビジネスは「ああ、私にはわかりません」と言います。これは、BDDの実行をやめ、より迅速なフィードバックを得るために何かを急上昇させ、ビジネスが彼らが望んでいるものを解決するのを助けるための良い兆候です。アイデアが安定したら、シナリオを振り返って書くことができます。
すべてのプロジェクトには、いくつかの新しい側面があり、そうでない場合はそうしません。
以前にやったことがあれば、退屈です
新しいdifferentiatingの側面に加えて、プロジェクトには通常、既に行われたものと同様のいくつかのcommoditisedの側面があります。たとえば、私が新しい携帯電話を製造している場合でも、電話をかける必要があります。 「電話をかける」というのはよく知られたシナリオなので、話をする必要はありません。同様に、「ログイン」や「ユーザー登録」なども退屈です。
可能な限り、これらのライブラリを使用すれば、それらの周りにシナリオを記述する必要はありません。また、他のビットを最初に実行します-すでにログインしているユーザーを持ち、彼がログインしているものをforを調べます。これらの領域は変更される可能性が低いため、いずれにせよ手動テストを回避できる可能性があります。
誰かが以前にそれをしたことがある場合、シナリオを通して話すことが役立ちます。
ドメイン固有の要件がある場所、someoneによって比較的よく理解されているもの、および実際の不確実性がほとんどの場合、実際の動作ではなくスコープの周りに少しありますシステム。
シナリオを通して話すことは、開発チームが行動を発見し、専門家の知識を利用し、既知の価値ある行動が確実にキャプチャされるようにするのに役立ちます。
これは、BDDが最適に機能するビットです。私のヒントは、機能ファイル（または自動化していない場合はwiki）の一番上に最も興味深いシナリオを記述し、重複している、または結果として推測しやすいシナリオを削除することです。
可能な限り、アプリケーションがどのように機能するかの例の例と同様にシナリオを使用してください。たとえば、検証がどのように機能するかを示したい場合は、アプリケーションがユーザーがフォームに入力するのをどのように支援するかの例をいくつか示します。単体テストを使用して検証が厳密であることを確認します。これにより、保守がはるかに容易になり、実行が速くなります。
さらに読む
これに興味があるなら、私が書いたいくつかの助けになるかもしれないものがここにあります。
Cynefin for devs 、これらの3つの領域について詳しく説明します
私のチュートリアルスライド 、これはすべてニースであり、注釈が付けられており、スタック全体もカバーしています。
去年の秋、かなり複雑な（ドメインの複雑さ）プロジェクトを構築しました。正直に言って、BDDに事前の作業を行うことでプロジェクトが保存されました。ドメインの複雑さとBDDの利点との間に強い相関関係があることを確認しました。
ひとつのことを言いましょう。複雑なビジネスルールのテストは難しいです。問題は、変更を加えるたびにすべてのクレイジーなシナリオを試して覚えたいですか、それとも仕様を破ったときにそのセーフティネットで通知するかです。事前の時間を費やしてすべてのシナリオを解決し、それらを書き留め、最終的にそれらのすべてのテストを記述します。
そして、後で意味を理解しようとして戻ってきたときに、そのテスト可能な仕様を用意することは、命の恩人です。
BDDはTDD（テスト駆動開発）に基づく開発プロセスです。ここでは、私の個人的な経験から得られたTDDの長所と短所をいくつか示します。
- TDDは、スコープが明確に定義されていることを確認します。このようにして、最初にテストケースを設計します。これにより、作成するコードに期待値を設定します。
- TDDは、コードを保護する方法です。単純な関数を作成し、後で同じ関数に複雑な切り替え条件を追加するとします。明日、誰かがこの関数を変更したい場合は、テストケースを参照できます。彼があなたの関数を変更したい場合、彼はテストケースも変更しなければなりません（ほとんどの場合）。これにより、彼/彼女はあなたが書いたものの背後に理由があったことを理解することができます。
- TDDを使用すると、ソフトウェア開発を迅速化できます。私たち一人一人がコーディング中にこの問題に直面したでしょう。アイデアから始めます。そして、ゆっくりとそれを見失う。最終的に、いくつかのシナリオを処理するために不要なコードを配置します。 TDDでは、期待を前もって設定します。これにより、目的から離れすぎないように制限できます。
- TDDを使用すると、プロジェクトがオンラインになる前に、起こり得るバグをキャッチできます。これは主に書かれたテストケースの品質に関係しています。
短所：
- 最初は、TDDは少し難しいかもしれません。多くの人は、開発を推進するテストケースの概念を理解していません。
- TDDは、メンテナンスに多大な労力を要します。これは、不要な、または無意味なテストケースに関係しています。
- TDDは、少々の塩で服用する必要があります。他の誰かが書いたテストケースに時間を費やすことを好む開発者はいません。テストケースの意味を解読すると、大きな頭痛の種になることがあります。
900,000行を超えるコードを含むプロジェクトに取り組んでいます。そして私はまだBDDに従っています。考慮すべき1つの主要なことは、純粋にテストケースが原因で検出される可能性のあるエラーの数です。数年後、あなたはBDDに誓うでしょう！