GUI测试的一个方法是提供一个交互录制器，监控测试人员，创建一个以后能够重用的脚本。这种方法存在若干问题：根据录制格式的不同，脚本在 UI改变之后可能难以修改；很自然地，测试优先的开发模式不可行。

　　与单元测试相比，GUI测试要耗时和困难的多，即使是在测试驱动的开发团队中，因此也常被忽视。让我们来看一看两个为SWT和Swing应用创建GUI测试的解决方案，它们均宣称能够使GUI测试工作更加简单。

　　为什么GUI测试难以编写？比起简单的实例化一个类，GUI通常需要更多的创建工作，同时因为GUI交互是异步的而且涉及到鼠标操作，所以难以模拟 用户行为。GUI测试的一个方法是提供一个交互录制器，监控测试人员，创建一个以后能够重用的脚本。这种方法存在若干问题：根据录制格式的不同，脚本在 UI改变之后可能难以修改；很自然地，测试优先的开发模式不可行。

　　另外一种选择是编程创建GUI测试。这依赖于框架是否适合编写测试。找到一个能够识别UI元素和相关设施，并能等待异步操作结束的简单并有效办法至关重要。SWTBot和Marathon都用于为Java应用编写GUI测试。SWTBot使用Java，所以存在使用JRuby的可能性。Marathon则更进一步，直接使用JRuby（或者Jython）编写测试脚本。

　　SWTBot

　　SWTBot是一个用于SWT、基于Eclipse应用的测试工具，提供了简化访问SWT和Eclipse组件的API。测试脚本可以通过Ant任务运行，因此你可以把测试集成到持续集成构建中。SWTBot基于Apache 2许可协议。

　　InfoQ采访了SWTBot的开发人员——Ketan Padegaonkar。Ketan在ThoughtWorks工作，因此我们询问了有关JRuby和DSL的发展动向：

　　毫无疑问，这些都在SWTBot的日程表上。SWTBot仍然缺少大量API，我们正在原来的基础上不断进步。SWTBot的大部分功能都是基于Twist开发团队的需求、反馈和SWTBot社区。目前还没有真正需要集成JRuby的理由。我相信这是因为没有太多人使用JRuby开发SWT/Eclipse。所以，JRuby集成目前还不在考虑中。

　　SWTBot 2.0（目前是beta版）组合了 FluentInterface和微型的DSL来查询widgets。我认为这是一种不断发展和提供足够句法支持而不使用完全JRuby方式的好办法。

　　SWTBot也提供了一个录制器，目前它处在什么状态呢？

　　录制器只是为了体现概念而开发，所有没有投放太多的精力在上面。它对大多数控件都不支持，也不会录制所有操作，虽然添加这些支持很简单。录制器采用中间格式录制代码，类似于抽象语法树。这种表示随后会输出成你选择的语言，目前它支持Java，但Ruby也是可以的。

　　还要注意：录制和回放不是编写测试的推荐方式（参见TestingGUIApplications和录制 vs. 编码）。这主要是因为一个工作流（或者所有脚本）的完整脚本在被测应用发生微小改动之后需要重新录制。SWTBot提倡采用PageObject/ScreenObject模式（或参见重用功能性测试）。

　　那么，未来有什么规划？

　　SWTBot对于参与其中的每一个人来说在很多方面都是一个学习的历程。SWTBot目前在进行第三次重写。我们在2.0版中改正了1.x版的很多错误。

　　我们移除了Java 1.4代码库以便使用Java 1.5的新功能，特别是泛型。我们也分解了SWTBot的一些子系统。这使得SWTBot更具扩展性，能够支持多页面编辑器、Eclipse富表单编辑器和GEF。

　　同时，申请把SWTBot移到eclipse.org，这可以方便更多用户访问SWTBot，使所有人受益。

　　一些有关使用SWTBot测试的好技巧可以浏览David Green的博客文章“Eclipse GUI Testing Is Viable With SWTBot”。

　　Marathon

　　与SWTBot相反， Marathon可以用于测试Swing应用。 Marathon带有自己的编辑器和测试运行器，也支持调试和提供Ant任务。 Marathon由Bangalore的Jalian Systems公司开发，基于GNU LGPL协议。我们采访了Marathon的主要维护者和开发人员Dakshinamurthy Karra。

　　相比SWT，已经有太多测试Swing应用的工具，所以我们询问是否计划支持WST：

　　我们计划发布一个基于Eclipse的商业版本。由于各种原因推迟了。我们希望在未来几个月能够发布。作为一个团队，我们目前关注的是添加对Web测试的支持。根据需求的不同，我们随时准备添加对SWT的支持。但目前我们收到了更多支持Web应用的要求。

　　Marathon支持JRuby和Jython，为什么选择这两种语言？

　　Jython是初期开发人员选择的语言。我们个人喜欢Ruby，所以添加了对JRuby的支持。Marathon架构支持插件式脚本模型。JVM支持的任何语言（Groovy，Bean shell，Clojure）都可以被添加进去。

　　另一个偏爱Ruby的原因是可以创建DSL。而且还计划（仍在萌芽阶段）添加基于关键字的测试。

　　我们非常乐于看到社区能贡献出针对其他语言的支持。

　　看到Marathon的屏幕截图，感觉界面类似于Eclipse，其中有什么联系吗？

　　我们正准备发布一个基于Eclipse的商业版本（暂定名MarathonITE——Marathon集成测试环境）。Eclipse是我们的开发平台，这是UI类似Eclipse的一个原因。当我们需要实现一个功能的时候——我们通常会看看eclipse是如何实现的。

　　没有计划把Marathon（开源版本）集成到某IDE。

　　使用JRuby（或者Jython）测试是把动态语言偷偷用在传统开发环境的一个好机会。

　　你又是如何创建UI测试的呢？