我剛剛遇到了BBD和specflow，它看起來很有趣。在編寫用戶故事時，他們通常處於高層次，而角色用戶使用GUI。所以在編寫場景時，他們通常會從高層次的系統進行GUI測試或集成測試。但是在解決方案中進一步降低單元測試呢？例如。服務端點，業務對象等。我應該爲這些應用程序編寫新的應用場景嗎？還是有辦法在低級別測試（單元測試）中重複使用相同的應用場景，還是應該複製並超出場景？使用Specflow場景進行集成測試和單元測試
如果我弄錯了，請讓我知道。
像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）。這與Domain Driven Design的「無處不在的語言」一致。將該語言帶入單元測試和代碼中，也可以幫助團隊與利益相關者進行交流，因爲您不必一遍又一遍地進行翻譯。
將給定/何時/然後寫入註釋還真的幫助我專注於提供實際將要使用的代碼，而不是試圖猜測所有邊緣情況。最好的質量代碼是你的不要寫的東西。
祝你好運！