将Specflow方案用于集成测试和单元测试

Question

我刚刚接触到BBD和specflow，它看起来非常有趣。在编写用户故事时，他们通常处于高层，参与者使用GUI。因此，在编写场景时，它们通常是来自系统高层的GUI测试或集成测试。但是，在解决方案中进一步深入的单元测试呢？例如，服务端点、业务对象等。我是否应该为这些编写新的场景，或者是否有一种方法可以将相同的场景重用于低级测试(单元测试)，或者我是否应该复制并跳过这些场景？

如果我全搞错了，请告诉我。

Answer 1

像SpecFlow这样的业务驱动开发框架旨在帮助技术团队成员更容易地与项目的非技术利益相关者进行沟通。

英语规范不容易维护或重构。由于阅读单元级测试或示例的人都是技术人员，并且能够阅读代码，因此我更喜欢在该级别使用单元测试框架，如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)。这与领域驱动设计的“无所不在的语言”是一致的。将这种语言带入单元测试和代码中也有助于团队与利益相关者进行对话，因为您不必一遍又一遍地翻译。

将给定/何时/然后放入注释中也确实有助于我专注于交付实际要使用的代码，而不是试图猜测所有的边缘情况。质量最好的代码是你不写的东西。

祝好运!