4

我阅读的一些资源.. 将 BDD 称为对“Bad TDD”的回应。

  • 行为规范与验证。测试和实施之间没有不恰当的亲密关系
  • 在业务开发测试人员之间使用普遍/共享语言
  • 术语强调“行为”而不是“测试”。所以 Given-When-Then、Context、Scenario、Examples vs Test Suites、Fixtures 和 Cases。
  • 现场规格

不知道我是否错过了更多的好处..请投入。

鉴于大多数用户（可能是本地现象）在规范的创建/详细说明/澄清中“合作”，但对编辑/查看/执行/维护自动化版本不感兴趣（当然，他们希望通过以下方式满足所有规范软件）：

xUnit（例如 NUnit）是否有任何方面阻止它成为 BDD 的好工具？

  • 根据规范编写是一种与工具无关的技能。
  • 无处不在的语言也是如此。只是需要努力才能把它弄出来
  • 注意上面提到的约束。假设我采用与 BDD Given-When-Then 风格一致的 xUnit 测试命名风格。
  • 我获得/创建了一个工具，该工具使用上述命名约定从测试结果文件中生成类似的“实时文档”。

有人可以在我定制的 BDD 地图上标记“这里有龙”吗...

4

1 回答 1

2

那么，这里是给你的龙。

  1. 无论您使用哪种语言，GUI 的自动化仍然很困难。
  2. 用业务理解的术语来表述基于代码的 DSL 更加困难。
  3. 编写 DSL 需要一点时间。

然而：

  1. 在代码中进行自动化往往会在出现问题时提供更快的反馈，并且更容易调试。在构建中包含 xUnit 也更容易。
  2. 维护基于代码的 DSL 更容易。
  3. 比编写 DSL 花费的时间要长得多。

需要注意的是，“对不良 TDD 的反应”可能是指 BDD 的早期阶段，当时我们在类级别而不是系统或应用程序级别进行操作。

我提供了使用 NUnit 和 C# 中的 DSL 或 Moq 编写的场景和单元级行为的示例。为我工作。除非有明显的好处，否则不要使用自然语言工具。我为其中一个做出了广泛的贡献，因此我觉得有权在不带偏见的情况下提出这个建议。

我希望我能给你超过 +1 来指出创建/详细说明/澄清和编辑/查看/执行/维护之间的区别！

于 2011-05-31T21:37:21.270 回答