6

BBD と specflow に出くわしたばかりで、とても面白そうです。ユーザー ストーリーを作成する場合、通常は高レベルであり、アクターは GUI を使用します。したがって、シナリオを作成するときは、通常、システムの上位レベルからの GUI テストまたは統合テストになります。しかし、ソリューションのさらに下にある単体テストについてはどうでしょうか。たとえば、サービス エンドポイント、ビジネス オブジェクトなどです。それらの新しいシナリオを作成する必要がありますか?それとも、同じシナリオを低レベル テスト (単体テスト) に再利用する方法はありますか?それともシナリオをコピー アンド ペーストする必要がありますか?

私がそれをすべて間違っているかどうか教えてください。

4

1 に答える 1

10

SpecFlowのようなBDDフレームワークは、技術チームのメンバーがプロジェクトの非技術的な利害関係者とより簡単に通信できるように設計されています。

英語の仕様は、保守やリファクタリングが簡単ではありません。ユニットレベルのテストや例を読むのは技術的でコードを読むことができる人だけなので、私はそのレベルでNUnitなどのユニットテストフレームワークを使用することを好みます。

多くの場合、シナリオは単体テストよりもはるかに複雑です。通常、それらは内部ビジネスロジックのいくつかの組み合わせをカバーしており、組み合わせを構成する各側面は、異なるコード単位の責任になります。したがって、シナリオのロジックはいくつかの異なる単体テストに分割され、それらをコピーすることはできません。

時々、シナリオを使用して単体テストをガイドします。少しのロジックが特定のコードユニットの責任になることに気付くかもしれません。そうすれば、シナリオから関連するステップだけをコメントとしてユニットテストにコピーできます。

// Given I have $100 in my account
var account = new Mock<Account>();
account.SetupGet(a => a.Balance).Returns(100);

var accountProvider = new Mock<AccountProvider>();
accountProvider.Setup(ap => ap.AccountFor("lunivore")).Returns(account);

// When I ask for $20
var atm = new ATM(accountProvider);
atm.PutInCardFor("lunivore");
int money = atm.RequestMoney(20);

// Then I should get $20
Assert.AreEqual(20, money);

// And my account should have paid out $20
account.verify(a => a.PayOut(20));

シナリオが書かれている言語をコピーすることをお勧めします（例:) PayOut。これは、ドメイン駆動設計の「ユビキタス言語」と一致しています。その言語を単体テストとコードの両方に取り入れることは、翻訳を何度も行う必要がないため、チームが利害関係者と会話するのにも役立ちます。

Gived / When / Thenをコメントに入れることは、すべてのエッジケースを推測しようとするのではなく、実際に使用されるコードの配信に集中するのにも役立ちます。最高品質のコードは、あなたが書かないものです。

幸運を！

于 2010-07-16T10:46:18.240 に答える