gwt - 如何测试 GWT 开发？

Question

只需谷歌搜索“TDD”和“GWT”即可轻松找到 this article作者在其中解释了如何在没有容器的情况下测试 GWT 应用程序。但是，我认为他的示例不是测试驱动的，因为他首先进行了所有设计，然后再编写测试，而不是“测试优先”。

这让我思考:是否可以在像 GWT 这样的 UI 上进行“测试优先”开发？有人说UI代码不适合TDD。但我认为通过采用MVC模式，也许我们至少可以测试驱动MC部分？ (所以V是UI部分，不能进行测试驱动开发)。

我们在文章示例中编写的第一个失败测试是什么？

Answer 1

测试驱动 UI 是有问题的，因为您通常不知道屏幕上想要什么，直到您在屏幕上看到它。因此，GUI 开发往往需要大量迭代，因此很难通过测试来驱动。

这并不意味着我们就放弃 TDD 而转向 GUI。相反，我们将尽可能多的代码从 GUI 中推出，只留下简单的连接代码。这种连接使我们能够进行所需的大规模迭代更改，而不会影响问题的本质。

Michael Feathers 几年前在一篇题为 "The Humble Dialog Box" 的文章中对这项技术进行了最好的描述。 。这也是 Model-View-Presenter 背后的基本理念四年前引起如此轰动的图案；现在已分为被动 View 和监督 Controller 模式。本问题中的文章链接利用了这些想法，但采用的是测试后而不是测试驱动的方式。

这个想法是测试驱动除 View 之外的所有内容。事实上，我们甚至不需要写很长时间的 View 。事实上， View 是如此简单，以至于它可能根本不需要任何类型的单元测试。或者如果确实如此，它们实际上可以被写在最后。

要测试驱动监督 Controller ，您只需确保了解数据将如何在屏幕上呈现。您不需要知道数据在哪里，或者字体是什么，或者它是什么颜色，或者任何其他导致 GUI 大规模迭代的外观问题。相反，您知道一个数据项将是某种文本字段。另一个是菜单，还有一个是按钮或复选框。然后，您确保 View 可以提出正确渲染这些项目所需的所有问题。

例如，文本框可能有默认值。 View 应该能够请求它。菜单中的某些项目可能呈灰色。 View 应该能够请求此信息。 View 提出的问题都是关于表示的，没有业务规则。

出于同样的原因，当发生任何变化时， View 将通知监督 Controller 。 Controller 将适本地修改数据，包括任何类型的验证和错误恢复，然后 View 可以询问应如何呈现该数据。

所有这些都可以进行测试驱动，因为它们都与视觉显示分离。这一切都与数据的操作和呈现方式有关，而不是数据的外观。所以不需要大规模迭代。