我正在尝试测试基于WebForms(asp.net)的简单UI，并遵循MVP模式以使UI更具可测试性。

在遵循TDD方法进行后端算法时，我发现有些单元测试重构是按照DRY原则(不要重复自己)的精神进行的。当我尝试使用Rhino Mocks将其应用于UI来验证我的交互时，在设置视图或者模型期望时，我在Controller测试中看到了许多共性。

我的问题是：我们通常进行多大程度的重构(如果有的话)？我很好奇，看看其他TDDer如何测试他们基于MVC / MVP的UI。

解决方案

回答

我使用MVP，在测试中，我尝试应用标准代码中的大部分重构。由于测试不同场景所需的细微差异，通常在测试中效果不佳，但是在部分内部可能存在共性，并且在可能的情况下我会合并。随着项目的发展，这确实减轻了以后需要进行的更改。就像在标准代码中一样，更改一个位置(而不是20个位置)更容易。

回答

我不会像标准代码那样重构测试。当我们将事物重构为通用基类，辅助方法等时，测试开始变得越来越晦涩。测试本身应该足够清晰。

DRY不是测试问题。

就是说，有许多通常要做的管道事情，应该将其抽象掉。

回答

我宁愿将单元测试视为纯功能程序，以避免必须对其进行测试。如果在两次测试之间有足够普遍的操作，那么我将对标准代码库进行评估，但是即使那样，我仍将避免重构测试，因为我倾向于拥有很多测试，尤其是针对GUI驱动的BL。

回答

我使用硒进行功能测试
我正在使用JUnit来测试我的控制器。

我将模拟出控制器使用的服务或者资源，并进行测试以查看控制器重定向到的URI等。

在这一点上，我还没有真正测试的唯一内容就是视图。但是我采用了功能测试来弥补。