单元测试和ASP.NET Web应用程序是我小组中的一个歧义点。良好的测试实践常常会陷入裂缝，并且Web应用程序最终会在没有测试的情况下运行数年。

造成这种痛苦的原因通常是围绕着编写UI自动化中间开发的麻烦。

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

解决方案

回答

我对应用程序进行分层，并至少从演示者/控制器(以喜好为mvc / mvp)到数据层进行单元测试。这样，我对所编写的大多数代码都有很好的测试覆盖率。

我已经将FitNesse，Watin和Selenium视为可以自动执行UI测试的选项，但是我还没有在任何项目中使用它们，因此我们坚持进行人工测试。 FitNesse是我所追求的产品，但我不能同时介绍TDD(这使我感到难过吗？希望不会！)。

回答

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

对于Web开发人员，我还是一个相对较新的人，我也正在研究许多未经测试的代码。

对我来说，我将UI保持尽可能的浅(通常只有几行代码)，然后测试其他所有内容。至少我可以放心，使它进入UI的一切都是正确的。

完美吗？也许不是，但是至少它仍然是高度自动化的，并且核心代码(大多数"魔术"发生在其中)仍然具有相当好的覆盖范围。

回答

如果我们适当地分离各层，则可以实现单元测试。正如Rob Cooper所暗示的那样，除了用于管理演示文稿的逻辑外，不要在WebForm中放置任何逻辑。所有其他填充逻辑和持久层应保存在单独的类中，然后可以分别进行测试。

为了测试GUI，有些人喜欢硒。其他人则抱怨这很难建立。

回答

一种常见的做法是将所有可以移出的代码移到可以单独测试的对象中。此类代码通常将遵循MVP或者MVC设计模式。如果我们搜索" Rhino Igloo"，则可能会找到指向其Subversion存储库的链接。该代码值得研究，因为它证明了我所见过的Web窗体上最好的MVP实现之一。

当遵循此模式时，后台代码将执行以下两项操作：

• 将所有用户操作转移到演示者。
• 演示者提供的渲染数据。

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

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

回答

已经尝试使Microsoft的免费UI自动化(包括在.NET Framework 3.0中)与Web应用程序(ASP.NET)一起使用。一家名为Artiso的德国公司恰好写了一篇博客文章，解释了如何实现这一目标(链接)。

但是，他们的博客文章还链接了一个MSDN网络广播，该网络广播使用winforms解释了UI自动化框架，在我对此进行了研究之后，我注意到我们需要AutomationId才能获得有关控件的参考。但是，在Web应用程序中，控件没有AutomationId。

我向托马斯·舒斯勒(Artiso)询问了这一点，他解释说这是InternetExplorer的主要缺点。他引用了一种较旧的Microsoft(MSAA)技术，并希望自己IE8可以做得更好。

但是，我也尝试了Watin，看起来效果很好。我什至喜欢Wax，它可以通过Microsoft Excel工作表实现简单的测试用例。

回答

Ivonna可以对观点进行单元测试。我仍然建议将大多数代码移至其他部分。但是，某些代码仅属于其中，例如对控件或者控件事件处理程序的引用。

回答

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

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

仔细选择要测试的内容，不要盲目地为所有内容编写测试。有时这是一项无聊的任务，所以不要加倍努力。如果编写过多的测试，则可能会在耗时的维护负担下放弃该任务。

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

不要相信自己。假设我们总是会犯错误，因此编写测试以使生活更轻松而不是更艰难。

如果我们对编写测试不满意，则可能是做错了;)