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）。这与Domain Driven Design的“无处不在的语言”保持一致。将该语言同时用于单元测试和代码也有助于团队与利益相关者交谈，因为您不必一遍又一遍地进行翻译。

将Given / When / Then置于注释中也真正帮助我专注于提供实际将要使用的代码，而不是试图猜测所有边缘情况。最优质的代码是您不写的东西。

祝你好运！

使用Specflow场景进行集成测试和单元测试

1 个答案: