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

  • Jon Arild Tørresdal
  • 王瑜珩

2009 年 9 月 7 日

话题:.NET语言 & 开发架构文化 & 方法

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

.NET语言 & 开发架构文化 & 方法