用于单元测试的SpecFlow/BDD？

Question

似乎互联网没有明确的答案,或一套原则来帮助我回答这个问题.因此,我转向SO上的伟大民众,以帮助我找到答案或指导思想:)

SpecFlow对于.NET中的BDD非常有用.但是,当我们谈论BDD时,我们只是谈论集成/验收测试,还是我们还谈论单元测试 - TDD的完全替代？

我只在小项目中使用它,但我发现即使是我的单元测试,SpecFlow也可以改进代码文档和语言思维.Converseley,我无法在一个地方看到测试的完整代码 - 因为步骤是碎片化的.

现在给你..........

编辑:我忘了提到我在RoR社区看到RSpec,它使用BDD风格的语法进行单元测试.

Answer 1

我最近开始使用SpecFlow我的BDD测试,但是,我仍然使用单元和集成测试.

基本上,我将测试分成了单独的项目:

• 眼镜
• 积分
• 单元

我的单元测试用于测试单个方法,不执行任何数据库调用或外部引用.我对单个方法调用(可能有时两个)使用集成测试,它们与外部资源(如数据库或Web服务等)进行交互.

我使用BDD来描述模仿项目的业务/域要求的测试.例如,我会有项目的发票生成功能的规格; 或者与购物篮一起工作.这些测试遵循

作为用户,我想要,为了

语义类型.

我的建议是根据您的需求分割您的测试.避免尝试使用SpecFlow执行单元测试.

Answer 2

我们甚至已经开始在单元测试中使用 Specflow。

这样做的主要原因（和好处）是我们发现它迫使您从行为的角度编写测试，这反过来又迫使您以与实现无关的方式编写，这最终导致测试更少脆弱且更易于重构。

当然，这也可以使用标准的单元测试框架来完成，但是您并没有像我们发现我们正在使用 specflow 和 gherkin 语法那样容易地指导您。

为 specflow 设置一些开销，但我们发现当您进行相当多的测试时（由于您可以通过 specflow 获得重要的步骤可重用性）或者您需要重构您的实现，我们发现这会很快得到回报。

此外，您还可以获得易于理解的可读性规范，这些规范对于团队的新成员来说很容易理解。