根据我对它们的有限经验，可执行需求（即将所有需求指定为损坏的自动化测试）已被证明非常成功。我曾参与过一个项目，在该项目中，我们非常重视创建高级自动化测试，这些测试可以执行给定用例/用户故事的所有功能。在我们开始这种练习之后，开发变得多么容易，这让我感到非常惊讶。编写测试后，实现功能变得非常容易，我们能够对系统进行重大的架构更改，并且对世界仍然像昨天一样工作充满信心。
我们遇到的最大问题是管理这些类型的测试的工具不是很好。我们经常使用 Fitnesse，因此我现在讨厌 Fit 框架。
我想知道 1) 是否有其他人有使用这种类型的测试驱动需求定义进行开发的经验，以及 2) 你们都使用了哪些工具来促进这一点。
【问题讨论】：
标签： testing process automation
我还使用过的主要工具是 FitNesse。我已经在几家公司使用它，效果非常好。我们确实有数以千计的测试用例，我们必须非常严格地组织和使用它们。
我尝试了一些其他工具，包括编写我自己的 DSL（特定领域语言）和使用 RSpec 之类的工具。我真的很喜欢 RSpec，但它肯定更像是一种开发工具而不是商业工具。
我知道 Rick Mugridge 一直在开发一个名为 ZiBreve (http://www.zibreve.com/visit.php?page=index) 的工具，它应该具有更强的重构支持。我自己没有使用过它，但我认识 Rick 并且和他谈过几次。我知道在 Agile 2008 上讨论了一些不同的方法来处理一般的 Fitnesse 测试。
除此之外，我还没有看到很多好的工具。即使是 WinRunner 之类的工具也适用于 QA 类型测试，但对于业务需求的探索性测试，FitNesse 或自定义 DSL 似乎是目前可行的方法。
【讨论】：
您可能想看看 Robot Framework (http://robotframework.org)。它类似于 FIT，但希望更容易集成到不同的测试工具、版本控制和持续集成中。测试数据中不同的抽象级别也使得数据的维护变得更加容易，当单独的test data editor变得更加成熟时，维护变得更加容易。 quick start guide 介绍了框架最重要的功能，也可作为可执行演示。
【讨论】：
我不得不为我的工作使用、测试和设置 Fitnesse 和它的一个竞争对手 GreenPepper ，我能说的是：
GreenPepper 是一个 confluence 插件（confluence 是来自 atlassian 的企业 wiki），并且在“企业”级工具中提供了许多您需要的东西，几乎不需要额外的工作：
GreenPepper 的主要缺点是：配置非常困难，文档差（尽管他们似乎正在研究它并且他们在论坛上的回答非常快）和而且它不是免费的，你必须为 confluence 和 GreenPepper 付费，加起来可能会不少。
Fitnesse 在我看来是非常基础的，很容易设置，它可以工作但仅此而已，你可以使用一些开源社区开发的 Fitnesse 插件，甚至一些 Fit 插件，例如 Eclipse 插件 (从健身测试文件构建夹具的骨架，前提是它的扩展名为 .fit，非常有用）。集成不理想，身份验证和访问权限管理很差，但它是免费，如果你需要什么，你可以做，因为它是开源的。
【讨论】：
我发现使用contracts 是一种很好的方法。元编程合同通常比您描述的集成测试类型低，但两者肯定不是相互排斥的。我发现合同有助于保持文档、实施和测试的同步——这是 TDD 的一个主要问题（并不是说它不是非 TDD 的问题）。
【讨论】：
我试过 Fitnesse，它真的很糟糕（尤其是与 SVN 的集成）。 并且我们公司开发了类似的带有fit引擎的开源工具：FitPro
我使用的另一个出色工具是Concordion。它有唯一的缺点 - html 格式的要求
【讨论】：
我的经验仅限于个人项目，并发现与您提到的几乎相同的优势。我推荐http://metacpan.org/pod/Test::Simple::Tutorial，这是我尝试基于测试的开发的灵感。 perl 测试模块看起来非常有用和灵活，虽然我没有什么可以比较它们的。
我还认为测试对于项目的维护期至关重要。如果您一开始就有很好的测试，那么以后可以节省大量时间和错误。我希望我在当前项目的测试中投入更多的精力。
【讨论】：