BDDは中規模から大規模のプロジェクトに拡張可能ですか？

BDD（Behaviour Driven Development）について読んだすべてのWebサイトで、要件を定義することがいかに明白で簡単かを示す非常にシンプルで素晴らしい例が見つかります。しかし、このプロセスを（電卓の例ではなく）大きな製品に実装しようとすると、物事がかなり複雑で読みにくくなる（または得られる）ことがわかりました。特に後でリクエストを変更することは、このための統合テストを修正するための多くの作業を意味します。

だから、BDDは本当に価値があるのだろうか？他の手法では解決できない問題を解決できますか？

私は上で最高の資源の一つだと思いBDDがある例により仕様の本。BDDテストを整理する方法と、要件が変更されたときにそれほど手戻りが発生しないように作成する方法について多くのことを説明しています。

テストで事態が複雑になったり複雑になったりした場合は、おそらく何か間違ったことをしている可能性があります。BDDおよびTDDでも同じです。良いテストを書くことは難しく、それを学ぶのに何ヶ月もかかります。

BDDの焦点は会話であることに気付くのに役立つかもしれません。BDDは実際には、良い副産物として回帰テストを提供する分析ツールです。

会話のあらゆるレベルでシナリオを使用しました。さまざまな利害関係者を特定して、リリースが好評を博す可能性があるかどうかを確認することから、モジュールまたはクラスがどのように動作するかを決定することまで。

これを簡単にするために提案できるヒントとヒントがいくつかあります。

あなたがそれをやったことがないなら、それは変わるでしょう。

ドメインまたはビジネスにとって新しいものはすべて変更される可能性があります。シナリオを介して話し合い、それらに疑問を投げかけ、ビジネスが「わからない」と言うと、あなたはこの空間にいることに気付くでしょう。それは、BDDをやろうとするのをやめ、より迅速なフィードバックを得るために何かを急ぐことを止め、ビジネスが望むものを解決するのを助ける良い兆候です。アイデアが安定したら、振り返ってシナリオを作成できます。

すべてのプロジェクトには、新しい側面があります。そうでない場合は、そうしません。

以前にそれをやったことがあるなら、それは退屈です。

新しい差別化の側面だけでなく、プロジェクトには通常、すでに行われているものと同様のいくつかのコモディティ化された側面があります。たとえば、新しい携帯電話を製造している場合でも、電話をかける必要があります。「電話をかける」というのはよく知られているシナリオなので、話をする必要はありません。同様に、「ログイン」や「ユーザー登録」なども退屈です。

可能な限り、これらのライブラリを使用してください。そうすれば、それらの周りにシナリオを書く必要がなくなります。また、他のビットを最初に実行します-既にログインしているユーザーを持ち、彼が何のためにログインしているかを調べます。これらの領域が変更される可能性は低いため、とにかく手動テストを回避できる場合があります。

誰かが以前にそれをやったことがあるなら、シナリオを通して話すのが助けになります。

ドメイン固有の要件がある場所、誰かが比較的よく理解しているもの、および実際の不確実性がシステムの実際の動作ではなく、主に範囲内にある場所の間には少しの間があります。

シナリオを通して話すことは、開発チームが行動を発見し、専門家の知識を活用し、既知の貴重な行動を確実に獲得するのに役立ちます。

これは、BDDが最もうまく機能するビットです。私のヒントは、機能ファイル（または自動化していない場合はwiki）の一番上に最も興味深いシナリオを作成し、結果として重複または推測しやすいシナリオを削除することです。

可能な限り、アプリケーションの動作方法の例としてシナリオを使用してください。たとえば、検証がどのように機能するかを示したい場合は、アプリケーションがユーザーがフォームに入力するのをどのように支援するかの例をいくつか示します。ユニットテストを使用して、検証が厳密であることを確認します。ユニットテストは、メンテナンスがはるかに簡単で、実行も迅速です。

参考文献

あなたがこれに興味を持っているなら、ここに私が書いたいくつかの助けがあります。

大規模なBDD

開発者向けのCynefin。これらの3つの領域について詳しく説明します。

私のチュートリアルスライド、これはすべてあなたにとって素晴らしい注釈付きであり、スタック全体をカバーしています。

昨秋、かなり複雑な（ドメインの複雑さ）プロジェクトを構築しました。正直に言って、BDDに先行作業を加えることでプロジェクトを保存できました。ドメインの複雑さとBDDの利点との間に強い相関関係があることがわかりました。

複雑なビジネスルールをテストするのは難しいことです。問題は、変更を加えるたびにすべてのクレイジーなシナリオを試して覚えておきたいのか、それとも仕様を破ったときにそのセーフティネットを知らせたいのかということです。事前に時間を費やし、すべてのシナリオを作成し、それらを書き留め、最終的にそれらのすべてのテストを書きます。

そして、後で物事を理解しようとして戻ってきたとき、そのテスト可能な仕様を持つことは命の恩人です。

BDDはTDD（テスト駆動開発）に基づいた開発プロセスです。個人的な経験から得たTDDの長所と短所を次に示します。

• TDD、スコープが適切に定義されていることを確認します。この方法では、最初にテストケースを設計します。それによって、あなたが書くことになっているコードに期待を設定します。
• TDDは、コードを保護する方法です。単純な関数を記述し、その後、この同じ関数に複雑な切り替え条件を追加するとします。明日、他の誰かがこの関数を変更したい場合、テストケースを参照できます。彼があなたの機能を変更したい場合は、テストケースも変更する必要があります（ほとんどの場合）。これにより、彼/彼女はあなたが書いたものの背後に推論があったことを理解することができます。
• TDDを使用すると、ソフトウェア開発を高速化できます。私たちはそれぞれ、コーディング中にこの問題に直面していました。アイデアから始めます。そしてそれをゆっくりと見失う。いくつかのシナリオを処理するために、不要なコードを配置することになります。TDDでは、期待を前もって設定します。それにより、目的から離れすぎないように自分自身を制限します。
• TDDを使用すると、プロジェクトがオンラインになる前に起こりうるバグをキャッチできます。これは主に、作成されたテストケースの品質に関係しています。

短所：

• 最初は、TDDには少し注意が必要です。多くの人々は、開発を推進するテストケースの概念を理解していません。
• TDDは、メンテナンスに多大な労力を費やすことがあります。これは、望ましくない、または無意味なテストケースに関係しています。
• TDDはひとつまみの塩分で服用する必要があります。他の誰かが書いたテストケースに時間を費やすことを好む開発者はいません。テストケースの意味を解読すると、大きな頭痛の種になることがあります。

私は、900,000行を超えるコードを含むプロジェクトに取り組んでいます。そして、私はまだBDDに従います。あなたが考慮する必要がある1つの主要なことは、あなたが純粋にテストケースのためにキャッチするかもしれない可能性のあるエラーの数です。数年後、あなたはBDDに誓うでしょう！