unit-testing - 将 Specflow 场景用于集成测试和单元测试

Question

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

如果我弄错了，请告诉我。

Answer 1

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)。这与领域驱动设计的“无处不在的语言”是一致的。将该语言带入单元测试和代码还有助于团队与利益相关者交流，因为您不必一遍又一遍地进行翻译。

将 Given/When/Then 放入注释中也确实帮助我专注于交付实际将要使用的代码，而不是试图猜测所有边缘情况。最好的代码是你不写的东西。

祝你好运!