我正在开发一个大型 GUI 程序，即使经过多年的开发，我仍然没有一个测试用例。我通过使用 Eiffel 删除了很多需求连同严格的编码和按契约(Contract)设计。
但有时我觉得进行单元测试可能会对我有所帮助。但是每当我尝试写下一些内容时，我很快就会遇到 GUI 测试的问题(恕我直言，这在研究方面仍然是一个开放的挑战)并且尝试将代码与环境隔离似乎更加困难。
将我的工作想象成为 Eclipse 之类的东西编写非常复杂的插件。
所以我的新想法是添加一个Lua应用程序的脚本接口(interface)并在程序内部运行测试而不是单独的单元测试。或者我真的应该尝试花费大量的重构时间(和模型对象编写)来使应用程序能够进行单元测试吗？
最佳答案
作为平衡测试方法的一部分，这可能是个好主意。 soru 指出的缺点是有效的，但这些可能是也可能不是什么大问题，具体取决于项目。
- 执行速度:使用外部工具的 GUI 自动化通常非常慢。嵌入式脚本引擎虽然不如编译时单元测试快，但比 GUI 测试快得多。
- 不是重新发明轮子:在创建 GUI 测试框架时，您通常必须在测试代码中复制应用程序逻辑。使用脚本引擎，您可以直接调用代码。
- headless 执行:使用 GUI 测试自动化，您执行测试的代理将需要一个 GUI 桌面，这在尝试将测试作业外包给其他机器时有一定的局限性(需要以交互方式登录，屏幕未锁定，等...)使用脚本引擎对 API 进行编码时，这不是问题。
话虽如此，通过嵌入式脚本引擎进行自动化测试的另一个缺点是编写测试可能很麻烦。测试作者需要了解应用程序模型，并且应用程序模型需要支持脚本。类和方法需要暴露给脚本引擎，并且这种支持可能参差不齐，具体取决于项目或您尝试测试的项目的一部分。根据我的经验，这会导致挖掘源代码以找出需要调用哪些类/方法才能编写测试(尽管作为测试人员，挖掘源代码并不是一个坏主意)。
关于unit-testing - 通过嵌入式脚本从应用程序内部进行测试是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1341507/