如何试驾GWT开发？

谷歌搜索"TDD"和"GWT"很容易导致这篇文章,作者解释了如何在没有容器的情况下测试GWT应用程序.但是,我认为他的例子不是测试驱动的,因为他先拥有所有设计,然后再编写测试,而不是"先测试".

这让我想到:是否有可能在像GWT这样的UI上进行"先测试"？有人说UI代码不适合TDD.但我认为通过采用MVC模式,也许我们至少可以测试MC部分？(因此V是无法开发测试驱动的UI部分).

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

测试驾驶UI是有问题的,因为在屏幕上看到它之前,您通常不知道屏幕上的内容.出于这个原因,GUI开发往往是大规模迭代的,因此很难通过测试来驱动.

这并不意味着我们只是放弃了用于GUI的TDD.相反,我们尽可能多地从GUI中推出代码,只留下简单的布线代码.这种布线使我们能够进行所需的大规模迭代更改,而不会影响问题的本质.

几年前,Michael Feathers在题为"The Humble Dialog Box"的文章中最好地描述了这种技术.这也是Model-View-Presenter模式背后的基本理念,四年前引起了轰动; 现在已被分为被动视图和监督控制器模式.这个问题中的文章链接利用了这些想法,但是以测试后而不是测试驱动的方式.

我的想法是测试除视图之外的所有内容.实际上,我们甚至不需要长时间写出视图.实际上,View非常简单,根本不需要任何单元测试.或者如果确实如此,它们实际上可以写在最后.

要测试驱动监控控制器,您只需确保了解数据在屏幕上的显示方式.您不需要知道数据的位置,字体是什么,或者是什么颜色,或者导致GUI大量迭代的任何其他外观问题.相反,您知道一个数据项将是某种文本字段.另一个是菜单,还有一个是按钮或复选框.然后,您确保View可以询问所需的所有问题,以便正确呈现这些项目.

例如,文本框可能具有默认值.View应该能够要求它.菜单可能有一些灰色的项目.View应该能够询问这些信息.视图所提出的问题都是关于演示的问题,并且缺乏业务规则.

出于同样的原因,该视图将告知监督控制器何时发生任何变化.控制器将适当地修改数据,包括任何类型的验证和错误恢复,然后View可以询问应该如何呈现数据.

所有这些都可以通过测试驱动,因为它们都与视觉显示分离.这都是关于数据如何被操纵和呈现的,而不是它的外观.所以它不需要大规模迭代.