哪个更好用，以及为什么在自动化基于TCL / TK GUI的应用程序的测试用例时：
BUTTON invoke
或者
event generate BUTTON <ButtonPress-1>
和带按钮释放的相同命令
答案 0 :(得分：2)
通常，在测试应用程序中的Tk按钮时，仅通过调用invoke方法（甚至通过调用已注册的-command调用的过程）来测试就足够了。您通常不应该尝试测试Tk本身（它有自己的测试套件）因为那时您只是将您的测试与您不完全控制的库纠缠在一起。这在单元测试中尤其适用;那些应该只检查你编写的代码（例如，响应它被调用的按钮调用的代码）而不是它是如何发生的。
但是有时你也应该进行更大规模的集成测试，以确保你不会遇到只在你把事情粘在一起时出现的问题。您只需要知道集成测试要复杂得多。例如，要正确生成按钮单击，您还需要生成（模拟）鼠标移动，以便在鼠标悬停在按钮上时生成单击（因为当鼠标位于鼠标上时，Tk按钮仅用于处理鼠标单击在他们身上，并通过<Enter>和<Leave>事件找到它;这是一个微妙的影响，但很重要）。听起来很简单，但很难做对。跨平台更难（更改字体大小，更改窗口管理策略等）我不是说“不要进行集成测试”。我只是说他们真的很尴尬。
这一切都不排除进行用户验收测试。对于GUI应用来说，这是重要的，因为它们总是（好的，应该）被设计成让用户与它们交互的东西;这是他们的观点。进行一种类型的测试并不意味着您不需要进行其他更高级别的测试;它应该让更容易让更高级别的测试通过......
如果您使用event generate触发按钮，则需要按顺序创建<Enter>，<ButtonPress-1>和<ButtonRelease-1>。< / p>
答案 1 :(得分：1)
嗯，他们测试的几乎但不完全一样。在第一种情况下，您可以在不触摸事件系统的情况下测试按钮的命令（或者是否禁用它）。在第二种情况下，您将测试按钮的行为是否应该给出事件（应该包括在生成按下和释放后调用命令）。
（ ETA：和之前的Enter事件，因为Donal在他的回答中注意到。抱歉，我错过了。而且，正如我相信他说的那样，默认绑定并不需要进行测试我的回答主要是讨论选择测试用例的“自上而下”和“自下而上”的方法。）
如果你是一个乐观主义者，你会通过生成事件进行测试。如果在生成事件后获得成功的命令调用，一切都很好。但是，如果测试失败，则无法确定链的哪个部分失败：绑定，命令选项的设置，命令本身，按钮的状态等。
如果你是一个悲观主义者，你将通过获取命令选项值并直接调用它，调用按钮上的invoke，生成事件以及可能的更多来分别测试链中的每个链接。如果所有这些测试都成功，一切都很好，就像上面一样。如果其中任何一个失败，您将立即知道需要修复的内容。
最好的策略可能是通过妥协来实现的：从“抽象”测试开始（在这种情况下，生成事件），如果你在某个地方遇到麻烦，还要添加详细的测试。有几十个测试只是确认一切正常似乎令人印象深刻，但除了惯性之外没有真正增加很多，如果规格发生变化你将不得不处理。