用于单元测试的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和小黄瓜语法这么容易地引导你。

对于specflow有一些开销设置，但我们发现当你进行了不少测试时（由于你可以通过specflow获得重要的步骤可重用性）或者你需要重构你的实现，这很快得到了回报。 p>

另外，你可以获得很好的可读规格，让新手很容易理解。

Answer 3

我将其视为集成测试，这意味着它不会取代作为TDD流程一部分编写的单元测试用例。有人会对此有不同的看法。 IMHO单元测试用例仅测试方法/函数，并且应该模拟和注入所有依赖项。当涉及集成测试时，您将注入真正的依赖项而不是模拟的依赖项。您可以使用任何单元测试框架进行相同的集成测试，但BDD为您提供了一种更简洁的方式来解释域特定语言中的集成测试用例，这是一种简单的英语（或任何本地化语言）。

钽，
Rajeesh

Answer 4

我在两个不同尺寸的应用程序上使用specflow进行BDD测试。一旦我们完成了句子命名约定的扭结，它就变得非常好。 BA和QA，甚至实习生都可以为应用程序编写BDD测试。

但是，我也用它进行单元测试。异端！我能听到你们中的一些人尖叫。但是，有很好的理由。该系统负责根据许多不同的数据进行许多计算或确定。由于大量单元测试需要输入所有这些数据以用于测试目的，因此通过specflow提供的表格格式管理用于单元测试的数据变得更加容易。以表格格式有效地模拟数据存储库，允许对不同的组件进行大力测试。

我不知道我是否会在每种情况下都这样做，但是在我使用它的时候，它使得为执行单元测试所需的数据量更加容易和清晰。

Answer 5

<强>假设：

• 单元测试是（小）“代码单元”
的测试
• 大多数“代码单元”的客户是其他程序员。
• 进行单元测试的部分原因是提供如何调用代码的示例。

<强>因此：

• 显然，单元测试通常应该用编程语言编写，“代码单元”的用户将使用该编程语言。

<强>然而

• 有时需要数据表来设置运行单元测试的条件。
• 大多数单元测试框架都不擅长使用数据表。

<强>因此：

• Specflow可能是某些单元测试的最佳选择，但不应该是您的默认选择。

Answer 6

最后，我们正在努力向客户提供客户想要的产品，因此除了SpecFlow之外我真的不需要编写单元测试。毕竟，它运用相同的代码库。我对BDD/ATDD/TDD还不熟悉，但除了“完整”并且严格遵守TDD之外，我发现不必编写更多的单元测试。

现在我想如果团队分散且开发人员无法运行整个应用程序，那么单独的单元测试将是必要的，但是开发人员可以访问整个代码库并且能够运行应用程序那么为什么还要写更多的测试呢。