我过去曾使用lettuce作为python。它是一个简单的BDD框架，其中规范是在外部纯文本文件中编写的。实现使用正则表达式来识别每个步骤，为规范中的每个句子提供可重用的代码。
使用scala，使用specs2或scalatest我被迫在实现中编写规范，使得无法在另一个测试中重用该实现（当然，我们可以实现它在某个地方的某个功能中）并且无法将测试实现与规范本身分开（我曾经做过的事情，为客户提供验证测试）。
结束语，我提出了一个问题：考虑到客户端验证测试的重要性，scala的BDD框架是否有一种方法可以从外部文件加载测试，如果测试中的句子尚未实现则引发异常如果所有句子都已实施，则正常执行测试？
答案 0 :(得分：11)
我刚刚发现cucumber plugin for sbt。测试将在test / scala下实现，规范将作为普通txt文件保存在test / resources中。我只是不确定图书馆的可靠性以及将来是否会得到支持。
编辑： 以上是以下插件的包装，它完美地解决了问题并支持Scala。 https://github.com/cucumber/cucumber-jvm
答案 1 :(得分：9)
这完全取决于权衡。黄瓜风格的规格非常棒，因为它是纯文本，非编码人员可以轻松编辑和阅读。
然而，它们作为规范也非常严格，因为它们根据功能和Given-When-Then强加了严格的格式。在specs2 for example中，我们可以编写任何我们想要的文本，并仅注释那些对系统或验证有意义的行。缺点是文本被注释，并且必须明确指定pending以指示尚未实现的内容。此外，注释只是对某些代码的引用，生活在某处，您当然可以使用通常的编程技术来获得可重用性。
BTW，link above是一个有趣的权衡例子：在这个文件中，第一个规范是“丑陋的”，但有更多的编译时检查，When步骤使用了这些信息来自Given步骤或我们没有Then -> When步骤序列。第二个规范更好，但也更容易出错。
然后是维护正则表达式的问题。如果编写功能的人与实现功能的人之间存在严格的分离，那么即使没有实质性的改变，也很容易打破实现。
最后，还有版本控制的问题。谁拥有该文件？我们怎样才能确保代码与规范同步？谁在需要时重构规范？
到目前为止，还没有完美的解决方案。我自己的结论是BDD工件应该由开发人员掌握并由其他利益相关者验证，如果它是可读的或者读取html / pdf输出，则直接读取代码。如果BDD工件由开发人员拥有，他们也可以使用自己的工具通过验证（尽可能使用编译器）和维护（使用自动重构）来简化生活。
答案 2 :(得分：6)
你说你自己很容易通过Scala为这种stuf（方法，函数，特征，类，类型......）提供的常规方法重用实现，所以实际上并没有问题在那里。
如果你想给你的客户提供一个没有代码的版本，你仍然可以给他们代码文件，如果他们不能忽略一点语法，你可能会写一个自定义的记者写出所有文本到一个文件，甚至可能用html或其他东西格式化。
另一种选择是使用JBehave或任何其他基于JVM的框架，它们应该可以毫无问题地使用Scala。
答案 3 :(得分：0)
Eric的主要设计标准是可执行规范开发的可持续性（通过重构），而不是由于简单文本的“美感”而导致的初始便利性。
请参阅http://etorreborre.github.io/specs2/
specs2的功能是：
Specs2在设计和实现方面都令人印象深刻。 如果你仔细观察，你会看到DSL可以扩展，同时你保持开发的类型安全和强大的域代码命令。
抛弃“更丑陋”的论点，并认真对待这一点会找到力量。 查看结构化表单和代码段