FEST — 一个GUI测试框架

说FEST是一个GUI（Swing, AWT）测试框架，似乎有一点太大了，它的项目网站称其为一组API，倒也合适，而且它给了我们写测试的一个很好的参考，而且我很惊讶的发现，它与我以前所做的东西在许多思想上非常的接近，也许这都是TestNG给我们的灵感。

这里是FEST的一个教程，其中的代码可以从这里下载，运行这些东西可能需要你知道TestNG的使用，我是在Eclipse中安装TestNG插件运行的。

说说FEST的几个亮点，也就是使用XUnit时一些好的实践：

DSL

?

测试脚本不同于程序，繁琐的东西很多，将代码简化并使之易读更加的关键，则写出类似下面的脚本则会好许多：

login.textBox(“username”).enterText(“Leia”);
login.textBox(“password”).enterText(“secret”);
login.button(“ok”).click();
login.optionPane().requireErrorMessage().requireMessage(“Please select a domai”);

我在以前的测试工作中也发现了这个秘密，那个时候我的测试对象非常多，可能是N个数据库，N个接口，N个WEB，如果不做这种优化，脚本会非常恶心。虽然那个时候我还不是很清楚DSL是什么，但现在我很高兴自己有时候还是有点创新。

但是当时我从中也发现了Java这种高级语言的限制，过强的语法检查无法让我们写出更简洁的代码，所以要寻求脚本语言，例如Groovy之类的支持，FEST也正在做这件事。

?

自定义报告

?

感谢许多TestNG为我们提供了很多的报告接口，所以FEST也对此加以利用，可以记录出现错误的时候界面截图，这与我以前的一个需求很类似，我原来做的测试，需要在报告中体现用例，所以便利用了TestNG的功能，将用例写入了报告。

不过FEST的实现有一点问题，它实现了一个org.fest.swing.testng.ScreenshotOnFailureListener，本意是在出错时调用这个listener的onTestFailure，可惜onTestFailure在@AfterMethod之后调用，而@AfterMethod已经将作案现场清理，看了一下TestNG的代码，发现这里还真的不好处理，有一点别扭。

?

抽象Assert

?

特殊的测试对象对于验证有自己特殊性，就像FEST所作的，看这里的代码：

login.optionPane().requireErrorMessage().requireMessage(“Please select a domai”);

如果用xUnit的什么assertEquals，代码一定会很罗嗦，编写我们自定已的方法，可以抛出assert的Exception我们的验证就变得清晰简单起来。

我对此也有一些其它的应用，我当年测试的东西，很多时候我甚至不是很确定我的用例的结果，有些时候我希望记录许多测试结果，所以修改了assert，让它们不会在第一个错误是抛Exception，而是记录一个标记并将信息记入报告，也算是对assert的改造吧。