Best practice for integrating TDD with web application development?单元测试和ASP.NET Web应用程序是我小组中的一个歧义点。 良好的测试实践常常会陷入裂缝，并且Web应用程序最终会在没有测试的情况下运行数年。 造成这种痛苦的原因通常是围绕着编写UI自动化中间开发的麻烦。 您或您的组织如何将最佳TDD做法与Web应用程序开发相集成？ 如果您适当地分离各层，则可以实现单元测试。正如Rob Cooper所暗示的那样，除了用于管理演示文稿的逻辑之外，不要在WebForm中放置任何逻辑。所有其他填充逻辑和持久层应保存在单独的类中，然后可以分别进行测试。 为了测试GUI，有些人喜欢硒。其他人则抱怨这很难建立。 我对应用程序进行分层，并至少从演示者/控制器(以您的喜好为mvc / mvp)到数据层进行单元测试。这样，我对所编写的大多数代码都有很好的测试覆盖率。 我已经将FitNesse，Watin和Selenium视为自动执行UI测试的选项，但是我还没有在任何项目中使用它们，因此我们坚持进行人工测试。 FitNesse是我所追求的产品，但是我不能同时介绍TDD(这使我感到难过吗？希望不会！)。 我通常会避免涉及依赖UI元素的测试。我更喜欢集成测试，它可以测试从数据库层到视图层的所有内容(但不测试实际布局)。 在新项目中编写一行实际代码之前，请尝试启动测试套件，因为以后很难编写测试。 仔细选择要测试的内容-不要盲目地为所有内容编写测试。有时这是一项无聊的任务，所以不要加倍努力。如果编写了过多的测试，则可能会因为耗时的维护而放弃该任务。 尝试将尽可能多的功能捆绑到一个测试中。这样，如果出现问题，错误将继续传播。例如，如果您有一个摘要生成类，请测试实际输出，而不是测试每个辅助函数。 不要相信自己。假设您总是会犯错误，因此编写测试以使您的生活更轻松而不是更艰难。 如果您对编写测试不满意，则可能是做错了;) 一种常见的做法是将所有可以移出的代码移到可以单独测试的对象中。此类代码通常将遵循MVP或MVC设计模式。如果您搜索" Rhino Igloo"，则可能会找到其Subversion存储库的链接。该代码值得研究，因为它演示了我所见过的Web窗体上最好的MVP实现。 当遵循此模式时，您的后台代码将执行以下两项操作： 演示者进行单元测试应该很简单。 更新：Rhino Igloo可以在这里找到：https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/ 这是一个很好的问题，我也将订阅:) 对于Web开发人员，我还是一个相对较新的人，我也正在研究很多未经测试的代码。 对我而言，我将UI保持尽可能的浅(通常只有几行代码)，并测试所有其他内容是否无效。至少我可以确信，进入UI的所有内容都是尽可能正确的。 完美吗？也许不是，但是至少它仍然是高度自动化的，并且核心代码(大多数"魔术"发生在其中)仍然具有相当好的覆盖范围。 Ivonna可以对您的观点进行单元测试。我仍然建议将大多数代码移至其他部分。但是，某些代码仅属于其中，例如对控件或控件事件处理程序的引用。 已经尝试使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工作表实现简单的测试用例。 |
