如何对 HttpContext.Current.Server.MapPath 进行单元测试答案

【问题标题】：How to do unit test for HttpContext.Current.Server.MapPath如何对 HttpContext.Current.Server.MapPath 进行单元测试
【发布时间】：2013-10-30 22:21:11
【问题描述】：

我在我的方法中使用HttpContext.Current.Server.MapPath() 来获取文档。

为此方法编写单元测试，

我需要做什么：

App.config
在我的单元测试方法中

我如何模拟这个？

我只对Current.Server.Mappath() 进行了单元测试，而不是Path.Combine()

【问题讨论】：

由于 MapPath 涉及 Web 服务器和文件系统，这并不是真正的单元测试，实际上您在这里唯一的选择是尝试模拟 HttpContext.Current - 这不是一项令人愉快的任务，也不是推荐...有什么不能更改代码的原因吗？您进行单元测试的方法是什么？您能解释一下它的功能吗？也许有更好的方法来构建它，这更有助于进行单元测试。
Unit testing for Server.MapPath的可能重复
@Liam 不是真的，因为在这个问题之后提出了另一个问题！所以如果有的话，另一个是这个的副本：）当然是同一个人，但短期记忆丧失超出了 SO 的范围。

标签： asp.net unit-testing

【解决方案1】：

可能最好的解决方案是避免使用Server.MapPath：例如，您可以替换：

Server.MapPath("~/MyFolder/MyFile.dat")

作者：

Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"MyFolder\MyFile.dat")

【讨论】：

我无法更改代码。我只接受了测试。不去改变。我提到的代码怎么办
这对我的情况不起作用。单元测试位于不同的项目中。
@Terence，处理此问题的一种方法是将相关文件作为链接包含在您的单元测试项目中，并将“复制到输出文件夹”设置为 true。

【解决方案2】：

这在调用静态方法的代码中很常见，在保持关注点分离和避免紧密耦合的同时很难进行测试。这是测试和模拟“不可测试代码”的通用方法：为其编写“外观包装器”。

为这些方法创建一个包装器。一个简单的类，其中包含合理命名的方法，并且只委托给不可测试的调用（通常是静态调用）
为该包装类创建一个接口
不要在客户端代码中直接调用不可测试的方法，而是使用包装器（使用步骤 2 中提供的接口注入依赖项）并在其上调用普通方法。
在您的单元测试中，使用您想要的行为模拟包装器。

这种方法有效地减少了耦合，分离了需要分离的关注点。当然，您仍然无法测试包装器本身的行为，但如果它足够简单（仅委托给原始调用），那么问题不大。

【讨论】：

这实际上是一个非常好的答案，但是对于不知道依赖注入意味着什么的人来说并不容易理解。这可能是另一个获得更多支持的原因......您可能应该提供一些简单明了的代码示例。

【解决方案3】：

这是我的建议：

在您的应用中：

  {...
         var destinationPath= IOHelper.MapPath(DatafeedFolderName);
    ...
  }

这是帮助方法的代码

public static string MapPath(string subFolder)
                {
                    return HttpContext.Current.IsNull()
                        ? Path.Combine(Directory.GetCurrentDirectory(), subFolder)
                        : HttpContext.Current.Server.MapPath(subFolder);
                }

并且单元测试可以使用：

 {...
     Assert.True(runtime_path, Directory.GetCurrentDirectory() + "\destimationPath"
...}

【讨论】：