私はBDDの概念を始めたばかりで、ScottBellwareのHerdingCodeの人たちとの話を聞いています。私はSpecFlowで遊んでいて、かなり気に入っています。
ブログ投稿「 BDDツールの分類（ユニットテスト駆動と受け入れテスト駆動）」と少しのBDD履歴で説明されているように、ATDDとTDDの違いを理解していますが、それは疑問につながります。
説明したように、BDDツール（MSpecなど）を使用しているのは、単なる別の単体テストフレームワークではありませんか？そうだと私には思えます。
さらに、これは、SpecFlowを使用して下位レベルのコンポーネント（リポジトリやサービスなど）を特定することが間違っていることを示唆しているようです。下位レベルのコンポーネントのATDDとTDDの両方に同じツールを使用できるのであれば、なぜそうすべきではないのですか？まだよくわからないようなぼやけた線が残っているようです。
提起する非常に重要なポイントの1つは、ビヘイビア駆動開発には2つのフレーバーがあるということです。 2つのフレーバーはxBehaveとxSpecです。
SpecFlow（Rubyスタックのキュウリに非常に似ています）は、受け入れ基準としてxBehaveBDDテストを容易にするのに優れています。ただし、ユニットレベルで動作テストを作成するための良い方法は提供されません。他にもいくつかのxBehaveテストフレームワークがありますが、SpecFlowは多くの注目を集めています。
ユニットレベルでのビヘイビア駆動開発には、NSpec （ RSpec for Rubyから直接インスピレーションを得たもの）をお勧めします。NUnitまたはMSTestを使用するだけでユニットレベルでBDDを達成できますが、それらはやや不十分です（コンテキストを段階的に構築するのは非常に困難です）。 MSpecもオプションであり、多くの作業が行われていますが、NSpecでは単純なものがあります（MSpecでコンテキストを段階的に構築できますが、継承が必要であり、複雑になる可能性があります）。
BDDの2つのフレーバーは、主に、それらが提供する直交する利点のために存在します。
ボウリングカタはかなり良い例です。
SpecFlowでの仕様は次のようになります（これも、ビジネスと直接通信するため、受け入れテストとして最適です）。
機能ファイル機能ファイルは、テストの一般的な方言です。
機能：スコア計算 私のパフォーマンスを知るために プレイヤーとして システムに合計スコアを計算させたい シナリオ：ガターゲーム 新しいボウリングゲームを考えると すべてのボールが側溝に着地したとき その後、私の合計スコアは0になるはずですステップ定義ファイル
ステップ定義ファイルはテストの実際の実行であり、このファイルにはSpecFlowのマッピングが含まれています
[Binding]
public class BowlingSteps
{
private Game _game;
[Given(@"a new bowling game")]
public void GivenANewBowlingGame()
{
_game = new Game();
}
[When(@"all of my balls are landing in the gutter")]
public void WhenAllOfMyBallsAreLandingInTheGutter()
{
_game.Frames = "00000000000000000000";
}
[Then(@"my total score should be (\d+)")]
public void ThenMyTotalScoreShouldBe(int score)
{
Assert.AreEqual(0, _game.Score);
}
}
同じボウリングカタのNSpecの例を次に示します。
class describe_BowlingGame : nspec
{
Game game;
void before_each()
{
game = new Game();
}
void when_all_my_balls_land_in_the_gutter()
{
before = () =>
{
game.Frames = "00000000000000000000";
};
it["should have a score of 0"] = () => game.Score.should_be(0);
}
}
ますます多くのBDDを実行すると、BDDのxBehaveフレーバーとxSpecフレーバーの両方が必要になることがわかります。xBehaveは受け入れテストに、xSpecは単体テストとドメイン駆動設計に適しています。
真のビヘイビア駆動ツールは、キュウリのようなものです。私たちは.NETコードに対して私の仕事でそれを使用します。これにより、システム全体の動作を定義する機能を記述し、機能を実行して、システムが期待どおりに動作することを確認できます。全体のプロセスは私たちにとって非常にうまく機能します。
ワイヤープロトコルを介してキュウリに接続するNStepと呼ばれる.net実装があり、ラムダを使用してC＃でステップ定義を記述できます...それはかなり素晴らしいです。
ステップ定義は次のようになります。
When("^I go to the \"([^\"]*)\" (?:[Ss]creen|[Pp]age)$", (string pageName) =>
{
var screen = ParseScreen(pageName);
GoToScreen(screen);
World.Browser.Wait(1000);
});
あなたの理解は私のものと一致していると思います。BDDは統合テストに適しており、通常、システムをエンドユーザーとしてテストします。例：
Given I am an authorised user
When I go to the front page
Then there should be a link to my profile with my username as the link text.
より詳細なレベルでリポジトリの単体テストを行わない理由はありません。どちらも便利で適切だと思います。
通常の単体テストツールだけを使用することはできませんか？ BDDはプロセスと考え方であるため、はい、どのツールでも実行できます（または、必要に応じてツールなしで独自に作成することもできます）。ただし、TDDツールには、BDDの方法で物事を行おうとすると、摩擦を引き起こす特定の仮定がありました。たとえば、TDDは、ソフトウェアのアーキテクチャー単位をテストしていることを前提としています。クラス、モジュール、サービス。一方、BDDは、システムの機能部分を指定していることを前提としています。
下位レベルのコンポーネントを説明するためにSpecFlow/Cucumberを使用する必要がありますか？ まず第一に、質問は少し見当違いだと思います。コンポーネントが動作を直接表していない限り、コンポーネントを説明する傾向はありません。私はまだ質問の精神が何であると私が信じているかについて答えます。
Cucumberのようなストーリー指向のツールは、顧客/ユーザーの観点から行動について話すのに最適です。それはあなたが素人が簡単に親しみやすい仕様を作ることを可能にすることができます。ただし、これらのツールを使用して大量の状態や複雑な状態を説明するのは面倒な場合があります。
単体テスト、またはrSpecやMachine.Specificationなどのコード指向の仕様ツールは、複雑な状態や大規模な状態のセットアップを処理する場合にはるかに便利です。言語で利用可能なさまざまなツールを使用して、状態を管理できます。継承や偽物/モックのようなもの。Machine.Specificationには、.NETを重視する人にとって、これに対するいくつかの優れたアプローチがあります。
では、Cucumberを使用して低レベルの動作を指定する必要がありますか？その特定の動作に対して高レベルの可視性を持つことが重要である場合にのみ、私は言います。私の現在のプロジェクトでは、システムの特定のビジネスルールを多用する部分を表すアーキテクチャコンポーネントを開発しました。これらのコンポーネントはCucumberで指定されていますが、システムの大部分はNUnitでカバーされています。
ところで、SpecFlowは、BDDを始めたばかりの.NETの人々にとっては本当に素晴らしく、親しみやすいものですが、最終的には本格的なCucumber+nStepに卒業したいと思うでしょう。キュウリの生態系は巨大で役に立ちます。SpecFlowははるかに小さいです。
また、nStepが提供するラムダ構文は、SpecFlowやCuke4Nukeなどのメソッドを装飾するよりもかなり優れています。
免責事項/背景： nStepで元の開発の一部を実行しましたが、現在のプロジェクトではSpecFlowを使用しています。私はここでBDDを紹介するために取り組んでおり、シンプルで親しみやすいものが必要でした。
BDDツールの分類に関するこのブログがTDDとATDDについて説明しているのは興味深いことです。Liz Keoghが指摘するように、BDDは会話と探索に関するものです。関係するすべての人が貢献し、意図を伝え、アイデアを共有し、他の人を理解するのが簡単であるなど、適切なソリューションとより優れたソフトウェアをより早く構築できます。最終的にツールパスをたどるとき、ソフトウェアプロジェクトの利害関係者間のコラボレーションを最もよくサポートするツールは何ですか？
TDD、BDD、およびATDDの違いに関するこのブログに基づいて、 BDDツールには少なくとも3つの異なるフレーバーがあると言えます。
JUnitは、開発とテストに関する私たちの見方を変えました。その強みの1つは、テストをアプリケーション自体と同じプログラミング言語で記述できることです。したがって、デリバリーチームですでに持っている知識に基づいて構築することができます。テストが開発を推進するためにさえ使用されるとき、私たちはTDDの天国に到達します。
プログラミング言語は冗長性を減らすために最適化されています。これは、開発者の最悪の罪の1つであるRonJeffriesによるものです。したがって、技術テストを行う際にこれらのツールを使用して製品を正しく構築することがよくあります。これらのツールは、最も効率的になるのに役立ちます。
ユニットテストは実際には読みにくいため、何人かの人が自動テストをより理解しやすくしようとしました。最初の試みの1つは、単体テストを解析し、開発者以外でも読める簡潔な要約を提供することでした。たとえば、TestDox / AgileDoxはJUnitテストクラスのメソッド名から簡単なドキュメントを作成するか、PickelsはGherkinで記述された機能ファイルに基づいてドキュメントを生成します。
MSpecなどのフレームワークは、読みやすく、さらに読みやすい出力を提供するテストを作成するのに役立ちます。これらのBDDツールのフレーバーは、人間が読める形式の出力に焦点を合わせています。これにより、開発者が仕事をした後、開発者以外の人が参加できるようになります。
開発サイクルの早い段階で利害関係者を巻き込むために、読みやすい入力に焦点を当てた新しいツールが作成されました。Cucumberは、プレーンテキストファイルを利用して、自動テスト用の人間が読める形式の入力を提供します。テキストファイルには、given-when-then構造に基づいて特別に構造化された言語で記述されたシナリオが含まれています。これらのフレームワークは、受け入れ基準の共同定義をサポートする優れたツールです。
BDDのアイデアと並行して、FITが初期の代表であった別の種類のツールが開発されました。この統合テストのフレームワークを使用すると、例に関連するドキュメントに埋め込まれているテーブル内の例を指定できます。これらのドキュメントを作成するために開発スキルは必要ありません。また、純粋にテキストベースであるため、技術者以外の人でも簡単に読んだりレビューしたりできます。さらに、ドキュメントはプレーンテキストファイルではなく、リッチエディタの出力であるため、テキストを構造化できます。
FitNesseを使用すると、Wikiに基づいて予想される動作を共同で指定できます。Wikiはアクセスと使用が簡単であるため、エントリと学習曲線が低く、チーム全体の共通の作業を推進します。多くのアジャイル支持者は、コラボレーションの最良の方法は対面のコミュニケーションであると強調しています。しかし、あなたが考え、議論したことを書き留めるなら、それは可能な限り豊かでよく構成されているべきです。
Concordionは、段落、表、および適切な句読点を使用して通常の言語で要件を記述できるため、多くの柔軟性を提供します。説明の任意の部分を、自動テストへの入力として、およびテスト対象のシステムの出力の検証に使用できます。HTMLに基づいているため、ドキュメントを構造化し、画像を統合できます。簡単に言うと、予想される動作を説明するWebの表現力があります。
3種類のツールすべてでBDDを実装できますが、それぞれに長所と短所があります。ユニットテストフレームワークとxSpecのようなツールは、プログラミングの長所を完全に活用しています。これらは開発者向けの開発者向けツールであるため、技術的な部分を正しく理解しようとする場合に最適です。
アプリケーションの意図を伝えたい場合は、編集者が作業に使用するツールと強く関連しているツールを使用したほうがよいでしょう。仕様に入力と期待される出力のみが含まれている場合、それを読む人は誰でも、入力と期待される出力の関係からアイデアを再構築する必要があります。ヘッダーの仕様の目的を説明する簡単な説明は、読者が仕様の構造を理解するのに役立ちます。例による仕様に基づくドキュメントは、次のようになります。
はい、SpecFlowはかっこいいです、NSpecはかっこいいです...
FitNesseとConcordionもかっこいいです