单元测试建议 - 如何对.asmx进行单元测试

Question

我刚刚创建了一个非.NET内部自定义系统将使用的Web服务。关于在.NET 3.5环境中专门针对.asmx（最佳实践，如何测试调用，不执行哪些操作等）设置测试类和方法的最佳方法，我想提供一些建议。

我将使用NUnit进行此测试。它是否像创建测试项目一样简单，向其添加服务，然后创建测试类和该服务的实例..然后开始创建测试方法？

我需要测试.asmx和.asmx.cs方法（单元测试方法），以便我知道是否将其传递给队友，以便它能够正常工作。

也许直接测试.asmx.cs是不可能的，我只需要通过集成测试进行测试。我想我真正需要的是模拟我的.asmx。可能不可能。

Answer 1

单元测试的最佳实践不是测试asmx文件，而是测试asmx文件后面的部件（单元）。如果您可以将代码分成小块和单独的部分，那么您可以对这些部分进行单元测试。

如果您想测试asmx文件本身，那么您正在讨论集成测试。您可以按照您描述的方式使用NUnit，但这不是单元测试。

Answer 2

你可能会忽略其他人所说的话。 .asmx文件应该没有值得测试的逻辑。如果它真的只是业务层调用的包装器，那么它什么都不添加，不需要进行测试。如果确实添加了某些内容，请将其解压缩，直到.asmx只包含传递调用。

您的.asmx文件包含哪些内容无法提取到单独的可测试类中？

Answer 3

不幸的是，这是.asmx Web服务的问题，它们依赖于ASP.net，您最好的方法是将.asmx Web服务保留为存根，并将您的Web服务逻辑提取为干净的依赖关系 - 相反，免费课和单元测试。另一种方法是运行集成测试。

从长远来看，如果单元测试对您很重要，那么最好使用从一开始就使用单元测试设计的web service framework进行开发。

Answer 4

与Lodewijk一样，最佳做法是不对asmx文件进行单元测试。相反，将该文件中的逻辑提取到处理您所处行为的类文件中。这样，您就可以独立于UI对这些类进行单元测试。您可能会发现，您遇到的真正问题是UI层中存在太多业务逻辑。

如果您想测试asmx文件本身，您可能要考虑手动测试，集成测试或验收测试...但如果您可以将逻辑移动到业务层，您可能会发现它更容易测试。