将TDD与Web应用程序开发集成的最佳实践?

如果你 分开你的层 适当地。正如Rob Cooper所暗示的, 除了逻辑之外,不要在Web窗体中放置任何逻辑来管理您的演示文稿 . 所有其他的东西逻辑和持久性层都应该保存在单独的类中,然后您可以单独测试它们。

测试图形用户界面有些人喜欢 selenium . 其他人则抱怨这是一种痛苦的设置。

我将应用程序和至少单元测试从演示者/控制器(以您的偏好为准,MVC/MVP)分层到数据层。这样,对于编写的大多数代码,我都有很好的测试覆盖率。

我已经将Fitnesse、Watin和Selenium视为自动化UI测试的选项,但我还没有在任何项目中使用它们,所以我们坚持使用人工测试。Fitnesse是我所倾向的,但我不能像介绍TDD那样介绍它(这会让我很糟糕吗?我希望不是!).

这是一个很好的问题,我也将订阅它:)

我对Web开发还是比较陌生的,我也在研究许多基本上未经测试的代码。

对于我,我保留用户界面 尽可能轻 (通常只有几行代码)并测试其他东西。至少我可以有信心,让它进入用户界面的一切都是正确的。

完美吗?也许不是,但至少它仍然是高度自动化的,核心代码(大部分“魔法”发生的地方)仍然有很好的覆盖率。

我通常会避免依赖于UI元素的测试。我喜欢集成测试,它测试从数据库层到视图层(但不是实际布局)的所有内容。

尝试启动测试套件 之前 在一个新项目中编写一行实际的代码,因为以后很难编写测试。

仔细选择你要测试的东西——不要盲目地为每件事写测试。有时候这是一项无聊的任务,所以不要让它变得更难。如果编写的测试太多,那么在耗时维护的重压下,您可能会放弃该任务。

尝试将尽可能多的功能捆绑到单个测试中。这样,如果出了问题,错误也会传播。例如,如果您有一个生成摘要的类-测试实际的输出,而不是每个助手函数。

不要相信你自己 . 假设你总是会犯错误,所以你写测试是为了让你的生活更轻松,而不是更困难。

如果你对写测试感觉不好,那么你可能是做错了;)

一个常见的实践是将所有可以从代码隐藏中移出的代码移动到一个可以单独测试的对象中。此类代码通常遵循MVP或MVC设计模式。如果你在“犀牛冰屋”上搜索,你可能会找到它的颠覆资源库的链接。这段代码值得研究,因为它演示了我见过的Web表单上最好的MVP实现之一。

当遵循此模式时,您的代码隐藏将执行两项操作:

1. 将所有用户操作传输到演示者。
2. 呈现演示者提供的数据。

单元测试演示者应该是微不足道的。

更新:这里可以找到Rhino冰屋: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/

已经尝试让微软的免费用户界面自动化(包含在.NET Framework 3.0中)与Web应用程序(ASP.NET)一起工作。一家名为Artiso的德国公司恰好写了一篇博客,解释了如何做到这一点。( link )

然而,他们的blogpost还链接了一个msdn网络广播,解释了与winforms的ui自动化框架,在我看了这个之后,我注意到您需要automationid来获取对相关控件的引用。但是,在Web应用程序中,控件没有automationID。

我问托马斯·席斯勒(Artiso)这方面的问题,他解释说这是InternetExplorer的一个主要缺点。他提到了微软的一项老技术( MSAA )希望IE8能做得更好。

不过,我也给了瓦廷一个尝试,它似乎工作得很好。我甚至喜欢wax,它允许通过MicrosoftExcel工作表实现简单的测试用例。

Ivonna 可以单元测试您的视图。我仍然建议将大部分代码移到其他部分。但是,有些代码只是 属于 比如对控件或控件事件处理程序的引用。