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

你可能感兴趣的:(StoryTeller与可执行规范-采访Jeremy D.Miller)