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 放入注释也确实有助于我专注于交付实际将要使用的代码，而不是试图猜测所有边缘情况。最好的代码是你不写的东西。

祝你好运！