谷歌搜索'TDD'和'GWT'很容易导致this article，作者解释了如何在没有容器的情况下测试GWT应用程序。但是，我认为他的例子不是测试驱动的，因为他先拥有所有的设计然后再编写测试，而不是'先测试'。
这让我想到：是否有可能在像GWT这样的UI上进行“先测试”？有人说UI代码不适合TDD。但我认为通过采用MVC模式，也许我们至少可以测试MC部分？ （因此V是无法开发测试驱动的UI部分。）
我们将在文章示例中首先编写的第一个失败测试是什么？
答案 0 :(得分：14)
测试驾驶用户界面存在问题，因为在屏幕上看到它之前，您通常不知道屏幕上的内容。出于这个原因，GUI开发往往是大规模迭代的，因此很难通过测试来驱动。
这并不意味着我们只是放弃了用于GUI的TDD。相反，我们尽可能多地从GUI中推出代码，只留下简单的布线代码。这种布线使我们能够进行所需的大规模迭代更改，而不会影响问题的本质。
几年前，Michael Feathers在题为"The Humble Dialog Box"的文章中最好地描述了这种技术。这也是四年前引起如此轰动的Model-View-Presenter模式背后的基本思想;现在已分为被动视图和监督控制器模式。这个问题中的文章链接利用了这些想法，但是采用了测试 - 而不是测试驱动的方式。
我们的想法是测试除视图之外的所有内容。实际上，我们甚至不需要长时间写出视图。实际上，View非常简单，根本不需要任何单元测试。或者如果确实如此，它们实际上可以写在最后。
要测试驾驶监控控制器，您只需确保了解数据在屏幕上的显示方式。您不需要知道数据的位置，字体是什么，或者是什么颜色，或者导致GUI大量迭代的任何其他外观问题。相反，您知道一个数据项将是某种文本字段。另一个是菜单，还有一个是按钮或复选框。然后，您确保View可以询问所需的所有问题，以便正确呈现这些项目。
例如，文本框可能具有默认值。 View应该能够要求它。菜单可能有一些灰色的项目。 View应该能够询问这些信息。视图所要求的问题都是关于演示的问题，并且没有业务规则。
出于同样的原因，该视图将告知监督控制器何时发生任何变化。控制器将适当地修改数据，包括任何类型的验证和错误恢复，然后View可以询问应该如何呈现数据。
所有这些都可以通过测试驱动，因为它们都与视觉显示分离。这完全是关于如何操纵和呈现数据，而不关于它的外观。所以它不需要大规模迭代。
答案 1 :(得分：3)
我已经通过GUI成功测试了Swing和GWT应用程序的开发。
“仅在GUI后面”测试忽略了模型代码和GUI组件之间的集成。当模型更改并从GUI接收输入并更新模型时，应用程序需要挂钩事件处理程序以在GUI中显示数据。如果手动完成，测试所有这些事件处理程序是否正确连接是非常繁琐的。
通过GUI进行测试时要解决的最大问题是如何在开发过程中处理GUI的更改。
GWT有助于解决这个问题。您需要在GWT小部件上设置调试ID，并将DebugID模块导入您的应用程序。然后，您的测试可以通过控制Web浏览器，按ID查找元素并单击它们或在其中输入文本来与应用程序交互。 Web Driver是一个非常好的API。
然而，这只是一个开始。您还需要将测试与GUI结构分离：用户如何浏览UI以完成工作。无论您是通过GUI还是在GUI后面对控制器进行测试，都会出现这种情况。如果您针对控制器进行测试，则控制器会指示用户浏览应用程序的不同视图的方式，因此您的测试将耦合到该导航结构，因为它已连接到控制器。为了解决这个问题，我们的测试通过“驱动程序”层次结构来控制应用程序。测试与驱动程序交互，使其能够执行以用户为中心的活动，例如登录，输入订单和进行付款。驱动程序通过导航并将数据输入GUI来捕获有关如何执行这些任务的知识。它通过使用较低级别的驱动程序来捕获如何通过“手势”执行导航和数据输入，例如单击按钮或在输入字段中输入文本。最终得到的结构如下：
这种层次结构通常用于以用户为中心的设计文献中（尽管术语不同）。