如何爲HttpContext.Current.Server.MapPath執行單元測試

我在我的方法中使用HttpContext.Current.Server.MapPath()來獲取文檔。如何爲HttpContext.Current.Server.MapPath執行單元測試

撰寫對這一方法的單元測試，

什麼我必須做的：

的App.config
在我的單元測試方法

我如何嘲笑這個？

我經受僅Current.Server.Mappath()不是Path.Combine()

2013-10-22 Jeeva Jsb

由於'MapPath'涉及Web服務器和文件系統，這不是一個真正的單元測試，現實中你唯一的選擇是試圖模擬HttpContext.Current - 這不是一個令人愉快的任務，也不建議...是否有一個原因，你不能改變代碼？你是單元測試的方法是什麼 - 你能解釋它的功能嗎？或許有更好的方法來構建它，這對單元測試更加有意義。 –

可能重複[單元測試Server.MapPath]（http://stackoverflow.com/questions/19563106/unit-testing-for-server-mappath） – Liam

@Liam不是真的，因爲其他問題後，這個問題！所以另一個是這個東西的重複，如果有的話:)授予它是同一個人，但是短期內存損失超出了SO的範圍。 –

這是典型的調用靜態方法的代碼，在保留關注點分離的同時進行測試非常困難，避免緊密耦合。下面是測試和模擬「不可測試代碼」的通用方法：寫一個「外觀包裝器」給它。

爲這些方法創建包裝。包含理智命名的方法，只有代表們不可測調用一個簡單的類（通常是靜態的調用）
創建於包裝類
的接口，而不是直接調用客戶端代碼不可測的方法，使用包裝（使用步驟2中提供的接口進行依賴注入）並調用其中的常規方法。
在你的單元測試中，用你想要的行爲來模擬包裝。

該方法有效地減少了耦合，並區分需要分離的問題。當然，你仍然不能測試包裝器本身的行爲，但是如果它足夠簡單（只委託原始調用），那麼它不是一個大問題。

來源

2013-10-22 14:15:56 Guillaume

這實際上是一個非常好的答案，但對於不知道依賴注入意味着什麼的人來說，這並不容易理解。這可能是爲什麼另一個人得到更多的讚揚...你應該提供一些簡單而簡單的代碼示例。 – Sushi271

也許是最好的解決方法是避免使用Server.MapPath做一個單元測試：例如，可以取代：

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

由：

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

來源

2013-10-22 07:09:37 Joe

我無法做代碼更改。我只經過測試。不要改變。如何爲我提到的代碼 –

在單元測試中，這不適合我。 – Ciwan

這不適合我的情況。單元測試位於不同的項目中。 – Terence

這是我的建議：

在您的應用程序：

{... 
     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" 
...}

來源

2015-06-11 21:11:28

如何爲HttpContext.Current.Server.MapPath執行單元測試

回答

相關問題