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