User interface Tcl tk测试自动化使用invoke vs event generate

在自动化基于TCL/TK GUI的应用程序的测试用例时，使用哪一个更好？为什么：

BUTTON invoke

或

事件生成按钮

---

按钮释放的命令是一样的，他们测试的内容几乎相同，但并不完全相同。在第一种情况下，您可以在不接触事件系统的情况下测试按钮的命令（或是否禁用）。在第二种情况下，测试按钮的行为是否与给定事件的行为一致（该事件应包括在生成按下和释放后调用命令）

（ETA:以及Donal在回答中提到的在此之前的Enter事件。很抱歉，我错过了这一点。此外，正如我相信他所说的，默认绑定实际上不需要测试。我回答的要点是讨论选择测试用例的“自上而下”与“自下而上”方法。）

如果你是一个乐观主义者，你会通过生成事件来测试。如果在生成事件后成功调用了命令，则一切正常。但是，如果测试失败，您无法确定链的哪个部分失败：绑定、命令选项的设置、命令本身、按钮的状态等等

如果您是一个悲观主义者，那么您可以分别测试链中的每个链接，方法是获取命令选项值并直接调用它，在按钮上调用invoke，生成事件，甚至可能更多。如果所有这些测试都成功了，一切都很好，就像上面所说的。如果其中任何一个失败，您将立即知道需要修复什么

---

最好的策略可能是通过折衷实现的：从“抽象”测试开始（在本例中，生成事件），如果您在某个地方遇到问题，则添加详细的测试。有几十个测试来确认一切正常，这看起来令人印象深刻，但实际上并没有增加太多，除了在规范发生变化时必须处理的惯性。

通常，在应用程序中测试Tk按钮时，只需调用

invoke

方法就足够了（或者甚至通过调用注册的

-command

调用的过程）您通常不应该尝试测试Tk本身（它有自己的测试套件）因为你只是把你的测试和你不完全控制的库纠缠在一起。这尤其适用于单元测试；单元测试应该只检查你编写的代码（例如，按钮调用的代码）而不是如何发生的

但有时，您还应该进行更大规模的集成测试，以确保您不会遇到只有在将内容粘在一起时才会出现的问题。您只需要知道，集成测试要复杂得多。例如，要正确生成按钮单击，还需要生成（模拟）鼠标移动，以便在鼠标位于按钮上方时生成单击（因为Tk按钮只有在鼠标位于其上方时才会武装自己来处理鼠标单击，并通过

和

事件来发现这一点；这是一种微妙的效果，但很重要）.听起来很简单，但很难做到正确。跨平台（字体大小更改、窗口管理策略更改等）更难做到正确。我不是说“不要做集成测试”。我只是说它们真的很尴尬

所有这些都不排除进行用户验收测试。这对于GUI应用程序来说很重要，因为它们一直都是（好的，应该是）旨在让用户与他们交互；这是他们的观点。进行一种类型的测试并不意味着你不需要进行其他更高级别的测试；它只会让更高级别的测试更容易通过

---

---

如果您使用

事件生成

来触发按钮，则需要按顺序创建一个

、一个

和一个

。

哎哟。实际上，我创建了一个按钮是为了检查我对序列的回忆是否正确，但后来我分心了，再也没有完成它。谢谢您的回答。作为一名只负责进行系统级测试的测试工程师。我更喜欢使用事件生成方法，因为正如Hoodiecrow指出的那样，它更接近于模拟用户操作。使用invoke方法可能是开发人员的兴趣所在。感谢您指出这一步。

event generate BUTTON <ButtonPress-1>