【发布时间】：2010-09-06 07:47:53
【问题描述】：
单元测试和 ASP.NET Web 应用程序在我的团队中是一个模棱两可的点。通常情况下，良好的测试实践会落空，Web 应用程序最终会在没有测试的情况下运行数年。
这个痛点的原因通常围绕着在开发中期编写 UI 自动化的麻烦。
您或您的组织如何将最佳 TDD 实践与 Web 应用程序开发相结合？
【问题讨论】：
标签： unit-testing tdd
【发布时间】：2010-09-06 07:47:53
【问题描述】：
一种常见的做法是将所有可以使用的代码从代码隐藏中移出，并移到可以单独测试的对象中。这样的代码通常会遵循 MVP 或 MVC 设计模式。如果您搜索“Rhino Igloo”，您可能会找到指向其 Subversion 存储库的链接。该代码值得研究，因为它展示了我所见过的 Web 表单上最好的 MVP 实现之一。
当遵循这种模式时，您的代码隐藏将做两件事：
- 将所有用户操作传输给演示者。
- 呈现演示者提供的数据。
对演示者进行单元测试应该是微不足道的。
更新：Rhino Igloo 可以在这里找到：https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/
【讨论】：
我通常会避免涉及依赖 UI 元素的测试。我喜欢集成测试，它测试从数据库层到视图层的所有内容（但不是实际布局）。
尝试在在在新项目中编写一行实际代码之前启动一个测试套件，因为以后编写测试更加困难。
仔细选择您要测试的内容 - 不要盲目地为所有内容编写测试。有时这是一项无聊的任务，所以不要让它变得更难。如果您编写了太多测试，您可能会因为耗时的维护而放弃该任务。
尝试将尽可能多的功能捆绑到单个测试中。这样，如果出现问题，错误仍然会传播。例如，如果您有一个生成摘要的类 - 测试实际输出，而不是每个辅助函数。
不要相信自己。假设你总是会犯错，所以你编写测试是为了让你的生活更轻松，而不是更难。
如果你对编写测试感觉不好，你可能做错了；）
【讨论】：
如果你适当地分离你的层，单元测试将是可以实现的。正如 Rob Cooper 暗示的那样，除了用于管理演示文稿的逻辑之外，不要在 WebForm 中添加任何逻辑。所有其他的东西逻辑和持久层应该保存在单独的类中，然后你可以单独测试它们。
为了测试 GUI，有些人喜欢 selenium。其他人则抱怨设置起来很痛苦。
【讨论】：
-
好吧，也许 Selenium 对某些人来说是一种痛苦。但这就是其他人有工作的原因:)
Ivonna 可以对您的视图进行单元测试。我仍然建议将大部分代码移到其他部分。然而，一些代码只是属于那里，比如对控件或控件事件处理程序的引用。
【讨论】：
已经尝试让 Microsoft 的免费 UI 自动化（包含在 .NET Framework 3.0 中）与 Web 应用程序 (ASP.NET) 一起使用。一家名为 Artiso 的德国公司碰巧写了一篇博客文章，解释了如何实现这一目标 (link)。
但是，他们的博文还链接了一个 MSDN 网络广播，该网络广播解释了带有 winform 的 UI 自动化框架，在我看过这个之后，我注意到您需要 AutomationId 来获得对相关控件的引用。但是，在 Web 应用程序中，控件没有 AutomationId。
我向 Thomas Schissler (Artiso) 询问了这个问题，他解释说这是 InternetExplorer 的一个主要缺点。他引用了 Microsoft 的一项较旧的技术 (MSAA)，并希望自己的 IE8 能在这方面做得更好。
但是，我也尝试了 Watin，它似乎工作得很好。我什至喜欢 Wax，它允许通过 Microsoft Excel 工作表实现简单的测试用例。
【讨论】：
这是一个很好的问题，我也会订阅的:)
我对 Web 开发还是比较陌生，而且我也在研究大量未经测试的代码。
对我来说，我保持 UI 尽可能简洁（通常只有几行代码）并测试其他所有内容。至少我可以确信所有进入 UI 的东西都尽可能正确。
完美吗？也许不是，但至少它仍然是高度自动化的，并且核心代码（大部分“魔法”发生的地方）仍然具有很好的覆盖率。..
【讨论】：
我将应用程序分层，至少从演示者/控制器（无论您喜欢哪个，mvc/mvp）到数据层进行单元测试。这样，我对编写的大部分代码都有很好的测试覆盖率。
我已将 FitNesse、Watin 和 Selenium 视为自动化 UI 测试的选项，但我还没有在任何项目中使用它们，因此我们坚持进行人工测试。 FitNesse 是我倾向于使用的，但我不能像介绍 TDD 一样介绍它（这会让我变得糟糕吗？我希望不会！）。
【讨论】：