似乎互联网没有明确的答案，也没有一套原则来帮助我回答这个问题。所以我求助于 SO 上的伟大人物来帮助我找到答案或指导思想:)
SpecFlow 对于 .NET 中的 BDD 非常有用。但是当我们谈论 BDD 时，我们只是在谈论集成/验收测试，还是我们也在谈论单元测试——完全替代 TDD？
我只在小型项目中使用过它，但我发现即使对于我的单元测试，SpecFlow 也改进了代码文档和语言方面的思考。 Converseley，我无法在一个地方看到完整的测试代码 - 因为这些步骤是零散的。
现在给你…………
编辑：我忘了提到我在 RoR 社区中看到 RSpec，它使用 BDD 样式的语法进行单元测试。
【问题讨论】：
我最近开始使用 SpecFlow 进行 BDD 测试，但我仍然使用单元和集成测试。
基本上，我将测试分成单独的项目：
我的单元测试用于测试单个方法，不执行任何数据库调用或任何外部引用。我对与外部资源（例如数据库或 Web 服务等）交互的单个方法调用（有时可能是两个）使用集成测试。
我使用 BDD 来描述模仿项目业务/领域需求的测试。例如，我会有项目发票生成功能的规范；或使用购物篮。这些测试遵循
作为用户，我想，为了
语义类型。
我的建议是根据您的需要拆分测试。避免尝试使用 SpecFlow 执行单元测试。
【讨论】：
我们甚至已经开始使用 Specflow 进行单元测试。
这样做的主要原因（和好处）是我们发现它会迫使您从行为的角度编写测试，这反过来又会迫使您以更加与实现无关的方式进行编写，这最终会导致测试它们不那么脆弱，对重构更友好。
当然，这也可以使用标准单元测试框架来完成，但您不会像我们发现使用 specflow 和 gherkin 语法那样容易地指导您。
为 specflow 设置一些开销，但我们发现当您进行大量测试（由于您可以通过 specflow 获得重要的步骤可重用性）或您需要重构您的实现时，这很快就会得到回报。
此外，您还可以获得易于团队新人理解的可读性很好的规范。
【讨论】：
鉴于：
因此：
但是：
因此：
【讨论】：
我将其视为一种集成测试，这意味着它不会取代作为 TDD 流程的一部分编写的单元测试用例。对此会有不同的看法。恕我直言，单元测试用例只测试方法/功能，所有依赖项都应该被模拟和注入。在进行集成测试时，您将注入真正的依赖项而不是模拟的依赖项。您可以使用任何单元测试框架进行相同的集成测试，但 BDD 为您提供了一种更简洁的方式来解释使用纯英语（或任何本地化语言）的领域特定语言的集成测试用例。
塔，
Rajeesh
【讨论】：
我使用 specflow 在两个不同大小的应用程序上进行 BDD 测试。一旦我们解决了句子命名约定的问题，结果就很好了。 BA 和 QA，甚至实习生都可以为应用程序编写 BDD 测试。
不过，我也将它用于单元测试。异端！我能听到你们中的一些人尖叫。然而，这有很好的理由。该系统负责根据许多不同的数据进行许多计算或确定。由于许多单元测试需要输入所有这些数据以用于测试目的，因此通过 specflow 提供的表格格式管理用于单元测试的数据变得更加容易。以表格形式有效地模拟数据存储库，允许对不同的组件进行积极测试。
我不知道我是否会在所有情况下都这样做，但在我使用它的情况下，它使得执行单元测试所需的大量数据的布局变得更加容易和清晰。
【讨论】：
最后，我们试图向客户提供客户想要的东西，因此我真的不认为除了 SpecFlow 之外还需要编写单元测试。毕竟，它使用相同的代码库。我对BDD/ATDD/TDD 还很陌生，但除了“完整”和严格遵守 TDD 之外，我发现没有必要编写更多的单元测试。
现在我想如果团队分散并且开发人员无法运行整个应用程序，那么单独的单元测试将是必要的，但开发人员可以访问整个代码库并能够运行应用程序，那为什么还要写更多的测试呢。
【讨论】：