StoryTeller 与可执行规范－采访 Jeremy D.Miller

StoryTeller 是一个开发“可执行规范”的.NET 开源项目，项目的创建者Jeremy D.Miller 在上周宣布了 StoryTeller 的预览版。InfoQ 针对 StoryTeller 是什么、与 Fit/FitNesse 和 Cucumber 这些工具有什么不同、以及项目未来的发展采访了 Jeremy。

InfoQ: StoryTeller 是什么？

Jeremy: StoryTeller 是一个可以在.NET 项目中创建“可执行规范”的工具。想象一下，有一天你作为开发人员得到了一份详细的需求文档，而这份文档同时 也能够被业务人员所理解，完全避免了双方在对系统行为理解上的不一致，而且它还能够在持续集成环境中被当作自动化测试来运行。StoryTeller 使这 一切在.NET 环境中成为可能。

InfoQ: 是什么促使你编写 StoryTeller 的？

Jeremy: 我曾经在好几个公司和项目中使用 FitNesse 来创建自动化测试，有非常丰富的经验。我喜欢使用 FitNesse 来编写易于人们阅读的自动化测试，但是我的团队在使用 FitNesse 时常常遇到问题。我原本是 想为 FitNesseDotNet 库创建一个新的编辑器和测试管理工具，但做了一段时间后，放弃了这种方式，并从头开始创建了专门为.NET 打造的全新测 试引擎。一路走来，我认为我比当初设想的做得更好。我希望能有一种工具，可以做 FitNesse 能做到的事，同时还拥有更简洁的测试语言，更方便的机制来 让开发人员编写自动化测试代码，以及更容易与版本控制和持续集成工具整合。

而且坦率地说，开发开源软件的经历让我成为更好的开发人员。

InfoQ:你认为 StoryTeller 和其它类似的工具有什么不同，比如 Fit/FitNesse 和 Cucumber？

Jeremy: 让我澄清一下，StoryTeller 的目的是成为.NET 平台上更好的 Fit/FitNesse，它的大部分灵感都来源于我之前在 FitNesse 上的 经验。StoryTeller 使你能够创建“套件 (Fixture)”类来实现和创建“语法”，以便用英语语法来表达测试用例，在这一点上它与 FitNesse 很相似。它与 FitNesse 的不同是，StoryTeller 使用“映射机制”来显示 html 而不是像 FitNesse 那样解析 html。另一个不同则是工具方面，FitNesse 需要你在 Wiki 中以某种特定格式编写测试，这通常也是抱怨最多的地方；而 StoryTeller 使 用 WPF 编写的客户端程序来编写测试，这可以加快创建测试的速度。

Cucumber 是一个 Ruby 工具，它与 StoryTeller 要解决的问题是一样的，但是机制不一样。你可以使用 Cucumber 和 IronRuby 来为.NET 代码编写可执行规范，但是使用与功能代码相同的语言来编写测试会得到更多的好处。今天你可能使用 Cucumber 和 Ruby 来编写测试，因为 它能创建易于阅读的测试，但是通过 StoryTeller，你的开发人员可以使用 C#来编写这些测试

InfoQ: StoryTeller 只是开发人员的工具么？

Jeremy: 目前，StoryTeller 更倾向于给开发人员使用，因为你需要写代码，但是从长远来看，StoryTeller 将是测试人员和业务伙伴利用自动化验收测试表达需求的工具。我们的（一个）测试人员在很多地方都使用 StoryTeller。

InfoQ: StoryTeller 可以很容易的与 CI 工具集成么？

Jeremy: 当然，这是 StoryTeller 架构的主要目的之一。StoryTeller 中的一切都是“可 xcopy 部署”的。StoryTeller 测试只是存储 在文件系统中的 Xml 文件，工具本身对要测试的二进制文件的位置没有任何假设。对于 CI 构建，StoryTeller 包含一个命令行工具，可以在任何支持 命令行的构建工具中使用。我们使用 JetBrains Team City 来运行我们的 StoryTeller 测试套件，而且已经将测试结果集成到了我们的 Team City 网站。

InfoQ: 看来你已经在 Dovetail 项目中自己先试用 StoryTeller 了，这对于它的发展有多大帮助？

Jeremy: 试用 StoryTeller 是非常重要的。基于我们的使用经验，我消除了性能瓶颈。基于我们第一轮测试的负面反馈，我找到了一些方法来让创建套件 (Fixture) 和语法 (Grammar) 构件更加方便。早些时候，我们发现一些只用于生成测试语法的重复代码，于是我们在自动化测试中消除了这些重复。基于我们使用它的反馈，我经常需要改进 StoryTeller 显示测试结果和错误的方式，以便能更容易找到测试失败的原因。不久前，我投入了很多时间来让 StoryTeller 更好的处理编码错误，以便让开发人员在测试代码不工作时，能够知道到底发生了什么。最近，我们的团队终于加入了一个测试人员。她使用 StoryTeller 的方式和遇到的问题促使我加入最后一些功能，以便让编写测试更加容易。

InfoQ: 未来 StoryTeller 将会如何发展？

Jeremy: 最近可能不会有太大的进展。我希望能够从早期的使用者那里得到反馈。目前，StoryTeller 主要是面对开发人员，你至 少需要在编写测试之前，将套件 (Fixture) 的骨架代码写出来 －我是有意这么做的，因为 Dovetail 团队在很长时间里都只有开发人员，因此 StoryTeller 是为我的团队优化的。今后，我将为测试人员和业务 人员提供某种方式，使他们能够不依赖于开发人员来编写测试，这样就可以在开发之前写出可执行的规范了。

InfoQ: 感谢 Jeremy，更多信息和源代码请登陆 StoryTeller 项目主页。

查看英文原文： StoryTeller and Executable Specifications - Interview with Jeremy D. Miller