通过嵌入式脚本从应用程序内部进行测试是一个好主意吗？

Question

我正在开发一个大型GUI程序，即使经过多年的开发，我仍然没有一个测试用例。我通过使用Eiffel以及纪律编码和按合同设计来消除了很多需求。

但有时我觉得进行单元测试可能会对我有所帮助。但是每当我尝试写下来时，我很快就会遇到GUI测试的问题（恕我直言仍然是研究方面的公开挑战）并试图将代码与环境隔离似乎更加困难。

将我的工作视为为Eclipse之类的东西编写非常复杂的插件。

所以我的新想法是为应用程序添加一个Lua脚本接口，并在程序内运行测试而不是单独的单元测试。或者我是否应该尝试花费大量的重构时间（和模拟对象编写）来使应用程序单元测试能够运行？

Answer 1

脚本编写是测试的一个非常糟糕的选择，因为：

1. 它不会捕获实际的GUI或GUI到模型代码集成错误
2. 它会有很多很多脚本到代码的集成错误
3. 这是一种非常缓慢且低效的模型代码错误测试方法
4. 设置和维护比任何可以想象的单元测试框架需要更多的工作

如果您因某些其他原因碰巧在您的产品中编写脚本，那么测试它显然是必要的。但是纯粹为了测试而添加它几乎不会是一场胜利。

单元测试（或单元式集成测试）可能是最明显的替代方案。其他人是：

• 通过产品或工具进行GUI自动化，基于回放和记录。
• GUI脚本，有点像应用程序脚本，但它的GUI模型不是支持脚本的工作的应用程序，并且希望您选择的工具包已经完成了。
• 基于GUI的测试编码，类似于GUI脚本，但在您的主要开发语言中：编写填写文本字段，按下按钮等的代码。

您选择的应该主要取决于您的客户可以接触到的错误的种类和数量。

Answer 2

作为平衡的测试方法的一部分，这可能是一个好主意。 soru注意到的缺点是有效的，但根据项目的不同，这些可能会或可能不会有什么大不了的。

• 执行速度：使用外部工具的GUI自动化通常非常慢。嵌入式脚本引擎虽然没有编译时单元测试那么快，但它将比GUI测试快得多。
• 不重新发明轮子：创建GUI测试框架时，您经常需要在测试代码中复制应用程序逻辑。使用脚本引擎，您只需直接调用代码即可。
• 无头执行：使用GUI测试自动化，执行测试的代理将需要一个GUI桌面，在尝试将测试作业分配到其他计算机时需要一定的限制（需要以交互方式登录，屏幕未锁定，等...）使用脚本引擎编写API时，这不是问题。

有人说，通过嵌入式脚本引擎进行自动化测试的另一个缺点是，编写测试可能很麻烦。测试作者需要了解应用程序模型，应用程序模型需要支持脚本。类和方法需要暴露给脚本引擎，并且这种支持可能不稳定，具体取决于项目或您尝试测试的项目的一部分。根据我的经验，这导致挖掘源代码以确定需要调用哪些类/方法来编写测试（尽管，作为测试人员，挖掘源代码并不是一个坏主意）。

Answer 3

在我看来，任何测试方法都会：

• 让您对代码更有信心，
• 提高产品质量

......值得做。

单元测试只是达到目的的手段。

如果你的直觉告诉你在嵌入式Lua中编写测试会给你带来最大的收益，我说去吧。