14

我过去用生菜做蟒蛇。它是一个简单的 BDD 框架，其中规范写入外部纯文本文件。实现使用正则表达式来识别每个步骤，证明规范中每个句子的可重用代码。

使用 scala，无论是specs2还是scalatest，我都被迫将规范与实现一起编写，这使得无法在另一个测试中重用实现（当然，我们可以在某个函数中实现它）并且无法分离来自规范本身的测试实现（我曾经做过的事情，向客户提供验收测试以进行验证）。

最后，我提出我的问题：考虑到客户端验证测试的重要性，在 BDD 框架中是否有办法让 scala 从外部文件加载测试，如果测试中的语句尚未实现并执行是否所有语句都执行正常测试？

4

4 回答 4

12

我刚刚发现了一个sbt 的黄瓜插件。测试将在 test/scala 下实现，规范将作为纯 txt 文件保存在 test/resources 中。我只是不确定图书馆的可靠性以及将来是否会获得支持。

编辑：以上是以下插件的包装器，它完美地解决了问题并支持 Scala。 https://github.com/cucumber/cucumber-jvm

于 2013-03-13T15:59:39.443 回答
9

这都是关于权衡的。黄瓜风格的规范很棒，因为它是纯文本，非编码人员可以轻松编辑和阅读。

然而，它们作为规范也非常严格，因为它们基于特征和 Given-When-Then 强加了严格的格式。例如，在 specs2中，我们可以编写任何我们想要的文本，并且只注释那些意味着系统操作或验证的行。缺点是文本被注释并且pending必须明确指定以指示尚未实现的内容。此外，注释只是对某些代码的引用，它们存在于某个地方，您当然可以使用通常的编程技术来获得可重用性。

顺便说一句，上面的链接是一个有趣的权衡示例：在这个文件中，第一个规范是“丑陋的”，但是有更多的编译时检查该When步骤使用来自Given步骤的信息或者我们没有步骤顺序Then -> When。第二个规范更好，但也更容易出错。

然后是维护正则表达式的问题。如果编写功能的人和实现它们的人之间有严格的分离，那么即使没有实质性的改变，也很容易破坏实现。

最后，还有版本控制的问题。谁拥有该文件？我们如何确保代码与规范同步？谁在需要时重构规范？

到目前为止，还没有完美的解决方案。我自己的结论是，BDD 工件应该掌握在开发人员手中并由其他利益相关者验证，如果代码可读，则直接阅读代码或阅读 html/pdf 输出。如果 BDD 工件归开发人员所有，他们不妨使用自己的工具通过验证（尽可能使用编译器）和维护（使用自动重构）来简化工作。

于 2013-03-18T07:21:29.000 回答
6

您自己说过，通过 Scala 为此类 stuf 提供的常规方法（方法、函数、特征、类、类型 ...）很容易使实现可重用，所以那里没有真正的问题。

如果你想给你的客户一个没有代码的版本，你仍然可以给他们代码文件，如果他们不能忽略一点语法，你可能可以编写一个自定义报告器，将所有文本写到一个文件中，也许甚至格式化为html或其他东西。

另一种选择是使用JBehave或任何其他基于 JVM 的框架，它们应该可以毫无问题地使用 Scala。

于 2013-03-13T16:07:13.577 回答
0

Eric 的主要设计标准是可执行规范开发的可持续性（通过重构），而不是由于简单文本的“美感”而带来的初始便利。

见http://etorreborre.github.io/specs2/

specs2的特点是：

  1. 默认情况下并发执行示例
  2. ScalaCheck 属性
  3. 用 Mockito 模拟
  4. 数据表
  5. AutoExamples，其中提取源代码来描述示例
  6. 丰富的匹配器库
  7. 易于创建和组合
  8. 可用于必须和应该
  9. 返回“功能”结果或抛出异常
  10. 可在 specs2 之外重用（例如在 JUnit 测试中）
  11. 用于编写类似 Fitnesse 规范的表单（使用 Markdown 标记）
  12. 用于创建验收测试文档的 HTML 报告，创建用户指南
  13. 使用始终最新的代码记录 API 的片段
  14. 与 sbt 和 JUnit 工具（maven、IDE...）集成

Specs2 在设计和实现上都令人印象深刻。如果您仔细观察，您会发现 DSL 可以扩展，同时保持类型安全和强大的域代码命令正在开发中。

抛开“更丑”的论点并认真尝试这一点的人会找到力量。查看结构化表格和摘要

于 2014-09-11T20:16:03.333 回答