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

Question

单元测试和ASP.NET Web应用程序在我的小组中是一个含糊不清的点。通常情况下，良好的测试实践会逐渐消失，Web应用程序最终会在没有测试的情况下上线数年。

这个痛点的原因通常围绕编写UI自动化中期开发的麻烦。

您或您的组织如何将最佳TDD实践与Web应用程序开发相集成？

Answer 1

如果适当地分离您的图层，则可以进行单元测试。正如Rob Cooper暗示的那样，除了逻辑之外，不会在WebForm中添加任何逻辑来管理您的演示文稿。所有其他东西逻辑和持久层应该保存在不同的类中，然后你可以单独测试它们。

要测试GUI，有些人喜欢selenium。其他人抱怨建立起来很痛苦。

Answer 2

我将应用程序和至少单元测试从演示者/控制器（取决于您的偏好，mvc / mvp）分层到数据层。这样，我对大部分编写的代码都有很好的测试覆盖率。

我已经将FitNesse，Watin和Selenium视为自动化UI测试的选项，但我还没有在任何项目中使用这些，所以我们坚持使用人工测试。 FitNesse是我倾向于的人，但我不能介绍这个以及引入TDD（这会让我变坏吗？我希望不会！）。

Answer 3

这是一个很好的问题，我也会订阅这个问题：）

我仍然是网络开发人员的新手，我也在看很多未经测试的代码。

对我来说，我保持UI 尽可能轻（）（通常只有几行代码）并测试其他所有内容。至少我可以确信，使用它的所有内容都尽可能正确。

完美吗？也许不是，但至少它仍然是非常高度自动化和核心代码（大多数“神奇”发生）仍然具有相当好的覆盖率..

Answer 4

通常的做法是将所有代码从代码隐藏中移出并转移到可以单独测试的对象中。此类代码通常遵循MVP或MVC设计模式。如果您搜索“Rhino Igloo”，您可能会找到其Subversion存储库的链接。该代码值得研究，因为它展示了我见过的Web窗体上最好的MVP实现之一。

当遵循这种模式时，你的代码隐藏会做两件事：

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

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

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

Answer 5

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

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

仔细选择您测试的内容 - 不要盲目地为所有内容编写测试。有时这是一项无聊的任务，所以不要让它变得更难。如果编写太多测试，则可能会在耗时的维护工作的重压下放弃该任务。

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

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

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

Answer 6

尝试使用Microsoft的免费UI自动化（包含在.NET Framework 3.0中）来处理Web应用程序（ASP.NET）。一家名为Artiso的德国公司碰巧编写了一篇博客文章，解释了如何实现这一目标（link）。

但是，他们的博客文章还链接了一个MSDN网络广播，用winforms解释了UI自动化框架，在我看了之后，我注意到你需要AutomationId来获得对尊重控件的引用。但是，在Web应用程序中，控件没有AutomationId。

我向Thomas Schissler（Artiso）询问过这个问题，他解释说这是InternetExplorer的一个主要缺点。他引用了微软的旧技术（MSAA），并希望自己IE8能够更好地做到这一点。

然而，我也在尝试Watin，它看起来效果很好。我甚至喜欢Wax，它允许通过Microsoft Excel工作表实现简单的测试用例。

Answer 7

Ivonna可以对您的观点进行单元测试。我仍然建议将大部分代码移到其他部分。但是，某些代码只是属于，就像对控件或控件事件处理程序的引用一样。