所有優秀的故事，他們總是從這4個神奇的單詞開始......我繼承了一個系統...不用等待！那是不對的！使用網絡配置的TDD
無論如何，隨着我現在通過幽默的嘗試，我沒有給予更多的東西，我必須支持現有的服務。
使用這項服務有許多問題，例如創建一個人的記錄，您需要調用4個不同的服務部分。
因此，與我的經理聚在一起之後，我們決定需要在頂部添加一個門面，以便爲常見請求添加正面，以簡化數字事物和創建新網站時正確的順序。
我的問題在這裏開始，如果有人想避免上面的華夫餅
所以我想對我做的工作中使用TDD，但是我繼承服務（這將成爲我們的數據層）與位於Web.Config中的特定連接字符串節點中的數據庫連接字符串強烈耦合。
問題我有，將服務從Config文件中分離出來需要幾周的時間，但我沒有。
所以我不得不將預期節點的App.Config文件添加到我的Test項目中。
可以這樣做，還是我應該開始投入一些時間從數據層中分離數據庫配置？
我同意你可能應該考慮使用依賴注入作爲你通過代碼解耦你的應用程序的方式，但是，我也明白這樣做並不是一件容易的事。
因此，要直接回答您的問題，不，添加配置文件以支持您的測試沒有任何問題。實際上，對於遺留系統的單元測試（遺留系統是未經測試的系統），這實際上很常見。如果沒有其他選擇，我還會採取反射的辦法，將假的配置值「注入」到ConfigurationManager中，以便測試讀取配置值的代碼，但這可能是最後的手段。
嘗試使用Dependancy Injection來模擬您的DataLayer。
在TDD中，您不是（必然）測試數據層和數據庫，而是測試BusinessLogic。
一些鏈接：
可以使用依賴注入來 「解開」 你的代碼的web.config（或app.config中對這個問題）：
正如您所說的，依賴注入是一種可行的方式。您還需要確保配置對象的使用者不依賴於特定的配置實現，例如ConfigurationManager，ConfigurationSections等。要查看使用自定義配置的完整示例，您可以查看我的博客文章Configuration Ignorance，但基本上它包含。
您的配置實現使用ConfigurationSection或XmlReader應該基於一個接口，您可以輕鬆地模擬出您的屬性並在以後輕鬆更改您的實現。
public BasicConfigurationSection : ConfigurationSection, IBasicConfiguration
{
...
}
要解決的配置是怎麼試，我們使用的配置提供商，特定配置的配置提供者知道如何找回它。如果你正在使用溫莎你可以再線配置
public interface IConfigurationProvider<TConfiguration>
{
TConfiguration GetConfiguration();
}
public class BasicConfigurationProvider : IConfigurationProvider<IBasicConfiguration>
{
public IBasicConfiguration GetConfiguration()
{
return (BasicConfigurationSection)ConfigurationManager.GetSection("Our/Xml/Structure/BasicConfiguration");
}
}
這直到溫莎的工廠設施。
希望有所幫助。
謝謝，希望我是好的。 – 2010-06-19 17:41:59