我HttpContext.Current.Server.MapPath()
在我的方法中使用来获取文档。
要为此方法编写单元测试,
我需要做什么:
- 应用程序配置
- 在我的单元测试方法中
我如何模拟这个?
我只为了Current.Server.Mappath()
不为Path.Combine()
我HttpContext.Current.Server.MapPath()
在我的方法中使用来获取文档。
要为此方法编写单元测试,
我需要做什么:
我如何模拟这个?
我只为了Current.Server.Mappath()
不为Path.Combine()
可能最好的解决方案是避免使用Server.MapPath
: 例如,您可以替换:
Server.MapPath("~/MyFolder/MyFile.dat")
经过:
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"MyFolder\MyFile.dat")
这对于调用静态方法的代码来说很典型,在保持关注点分离和避免紧密耦合的同时很难进行测试。这是测试和模拟“不可测试代码”的通用方法:为其编写“外观包装器”。
为这些方法创建一个包装器。一个简单的类,包含合理命名的方法,并且只委托给不可测试的调用(通常是静态调用)
创建该包装类的接口
不要在客户端代码中直接调用不可测试的方法,而是使用包装器(使用步骤 2 中提供的接口注入依赖项)并在其上调用普通方法。
在您的单元测试中,使用您想要的行为模拟包装器。
这种方法有效地减少了耦合,分离了需要分离的关注点。当然,您仍然无法测试包装器本身的行为,但如果它足够简单(仅委托给原始调用),那么问题就不是那么大了。
这是我的建议:
在您的应用中:
{...
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"
...}