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

如果您满足以下条件,则可以进行单元测试 将图层分开 适当。正如Rob Cooper所暗示的那样, 除了管理演示文稿的逻辑外,不要在WebForm中添加任何逻辑 所有其他东西的逻辑层和持久层都应该保存在单独的类中,然后您可以单独测试它们。

为了测试GUI,一些人喜欢 selenium 其他人则抱怨说,建立起来很痛苦。

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

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

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

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

对我来说,我保留了UI 尽可能轻 (通常只有几行代码)并测试其他所有内容。至少我可以有信心,所有进入UI的东西都是尽可能正确的。

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

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

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

仔细选择你测试的内容——不要盲目地为所有内容编写测试。有时这是一项无聊的任务,所以不要让它变得更难。如果你编写了太多的测试,那么在耗时的维护压力下,你就有可能放弃这项任务。

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

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

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

一种常见的做法是将所有代码从代码后面移到一个可以单独测试的对象中。此类代码通常遵循MVP或MVC设计模式。如果你在“Rhino Igloo”上搜索,你可能会找到它的Subversion存储库的链接。这段代码值得研究,因为它展示了我所见过的Web Forms上最好的MVP实现之一。

当遵循此模式时,你的代码后端将执行两件事:

1. 将所有用户操作传递给演示者。
2. 渲染演示者提供的数据。

演示者的单元测试应该很简单。

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

有人试图让微软的免费UI自动化(包含在.NET Framework 3.0中)与web应用程序(ASP.NET)配合使用。一家名为Artiso的德国公司恰好写了一篇博客文章,解释了如何实现这一目标( link ).

然而,他们的博客文章还链接了一个MSDN网络广播,该广播解释了使用winforms的UI自动化框架,在我看了这篇文章后,我注意到你需要Automation Id来获取相关控件的引用。但是,在web应用程序中,控件没有Automation Id。

我向Thomas Schissler(Artiso)询问了这一点,他解释说这是InternetExplorer的一个主要缺点。他引用了微软的一项旧技术( MSAA )他希望IE8能做得更好。

然而,我也给了瓦汀一次尝试,而且似乎效果很好。我甚至喜欢Wax,它允许通过Microsoft Excel工作表实现简单的测试用例。

Ivonna 可以对你的观点进行单元测试。我仍然建议将大部分代码移动到其他部分。然而,有些代码只是 应在 在那里,类似于对控件或控件事件处理程序的引用。