私が見ているのは、BDD がテストに別のレイヤーの間接化とセマンティック シュガーを追加していることですが、特に非技術者が内部 DSL を使用できる場合、付加価値は見られません。
余分なレイヤーはプレーンな言語.featureファイルであり、作成時点ではテストとは関係ありません。明確に定義されたストーリーを作成するために、例による仕様と呼ばれる手法を使用してシステムの要件を作成することに関係しています。ビジネス言語で適切に記述された場合、例による仕様は、共通の理解を生み出す上で非常に強力です。この作業だけでも、やり直しの量を減らすことができ、開発が始まる前に欠陥を見つけることができます。この演習は、意図的な発見としても知られています。
仕様について共通の理解と合意が得られたら、開発に入り、それらの仕様を実行可能にします。ここで ATDD を使用します。したがって、BDD と ATDD は同等ではなく、補完的なものです。ATDD の一環として、ストーリーの例として定義された動作を使用して、システムの開発を推進します。開発者にとって嬉しいのは、自動化できる事前条件、イベント、および事後条件を含む正式な形式です。
これ以降、CI システムで実行可能な仕様を自動実行すると、回帰が減少し、他の自動テスト手法から得られるすべての利点が得られます。
これらの非常に興味深い点は、実行可能な仕様ファイルが長寿命であり、システムに動作を追加/変更するにつれて、時間の経過とともに進化することです。ユーザーストーリーが開発された後に破棄されるほとんどのアジャイル方法論とは異なり、ここにはシステムの生きたドキュメントがあります。これは仕様でもあり、自動化されたテストでもあります。
健全な BDD 対応の配信プロセスを実行してみましょう (これが唯一の方法ではありませんが、私たちが好む方法です)。
- 意図的な発見セッション。
- 開発を推進する ATDD
- 継続的インテグレーション
- 出力 = スクリーンショット付きのレポートは、システムの閲覧可能なドキュメントです
- 自動導入
- アウトプット = 稼働中のソフトウェアが消費されている
- 測定して学ぶ
- アウトプット = 次の意図的な発見セッションを提供するための新しいアイデアとフィードバック
したがって、BDD は、ほとんどの配信システムに欠けている部分である仕様の部分で本当に役立ちます。これは通常、規律がなく、自由な形で行われ、数人の個人に任せられます。これが、BDD が単なるテスト手法ではなく、アジャイル手法である理由です。
それを念頭に置いて、他のいくつかの質問に答えさせてください。
キュウリの場合、stepDefs は、特定のテストを駆動するコードをいくつかの異なるクラスに分散させているように見え、機能ファイルの外部でテスト コードを読み取り、デバッグすることを困難にします。一方、1 つのテストに関連するすべてのコードを 1 つの stepDef クラスに配置すると、stepDef の再利用が妨げられます。どちらの結果も望ましくないため、自然言語の使用にこれほど多くの価値があり、直感的ではない間接的であることに何の価値があるのでしょうか?
stepDefs を自動テスト コードベースの上にある非常に薄いレイヤーにすると、複数のステップから自動コードを簡単に再利用できます。テスト コードベースでは、テスト ピラミッドや浅い深さのテストなどの手法や原則を利用して、堅牢で高速なテスト自動化レイヤーを確保する必要があります。この分離の興味深い点は、stepDefs とユニット/統合テストの間でコードを使用できることです。
足りないものはありますか？ATDD と BDD の微妙な哲学的な違いのようなものですか? 前者は命令的テストを意味するのに対し、後者は宣言的テストを意味しますか? これらの美的な違いには本質的な価値がありますか?
前述のように、ATDD と BDD は補完的であり、比較することはできません。命令的/宣言的という点では、技術としての例による仕様は非常に具体的です。意図的な発見フェーズを実行しているときは、常に「例を教えてください」という質問をします。その例では、正確な値を使用します。前提条件 (Given) またはイベント (When) ステップで使用できる 2 つの値があり、それらの結果 (Then ステップ) が異なる場合は、2 つの異なるシナリオがあることを意味します。同じ結果が得られる場合は、同じシナリオである可能性があります。したがって、BDD プラクティスの一部として、意図的な発見の利点を得るために、ステップは宣言的である必要があります。
したがって、テストを実行する実際のコードの可読性の低下を正当化する付加価値は何かという疑問が残ります。このBDDは実際に苦労する価値がありますか? 付加価値は単なる美学以上のものですか？
誤解の問題を解決したいチームで働いているなら、それは価値があります。BDD で人々が失敗する理由の 1 つは、機能の作成と自動化が開発者と QA に任されており、アーティファクトが生きている仕様として一貫性がなく、単なるテスト スクリプトであるためです。
テスト スクリプトは、システムが特定のことをどのように行うかを教えてくれますが、その理由は教えてくれません。
BDD の利点が BDD の痛みを上回る理由について、誰かが説得力のある議論を思い付くことができれば、私は感謝していますか?
それは、適切な仕事に適切なツールを使用することです。単体テストや自動化されたテスト スクリプトを記述するために Cucumber を使用することは、ハンマーを使用して木にネジを打ち込むようなものです。うまくいくかもしれませんが、決してきれいではなく、常に苦痛です!
ツールに関して言えば、一般的なビジネス アナリスト / プロダクト オーナーは、ソース管理を覗いて仕様の追加 / 変更を行うために必要な知識を持っていません。この問題を解決するための商用ツールを作成しました。これにより、チーム全体がクラウド内の仕様について共同作業を行い、リポジトリと同期 (リアルタイム) を維持できるようになります。シミアンをチェックしてください。
また、BDD についての質問にも答えました。開発に重点を置いているので、興味があるかもしれません。
TDD と BDD を組み合わせて使用する必要がありますか?