使用 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）。这与领域驱动设计的“无处不在的语言”是一致的。将这种语言引入单元测试和代码中还可以帮助团队与利益相关者进行对话，因为您不必一遍又一遍地进行翻译。

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

祝你好运！