0

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

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

我的问题是：如果有的话，你通常会在多大程度上进行这种重构？我很想知道其他 TDDer 如何测试他们基于 MVC/MVP 的 UI。

4

4 回答 4

1

我不会像标准代码那样重构测试。当您将事物重构为通用基类、辅助方法等时，测试开始变得更加模糊。测试本身应该足够清晰。

DRY 不是测试问题。

也就是说，有许多管道工作是常见的，应该抽象出来。

于 2008-09-17T00:00:20.137 回答
0

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

于 2008-09-12T20:49:52.907 回答
0

我更愿意将单元测试视为纯功能程序，以避免必须测试它们。如果一个操作在测试之间足够普遍，那么我会为标准代码库评估它，但即便如此我也会避免重构测试，因为我倾向于有很多它们，特别是对于 gui 驱动的 BL。

于 2008-09-30T21:46:53.033 回答
0

我使用 selenium 进行功能测试，我使用 JUnit 来测试我的控制器。

我将模拟控制器使用的服务或资源并测试以查看控制器重定向到的 URI 等...

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

于 2008-09-30T21:51:35.457 回答