編寫驗證屬性或配置的單元/集成測試是否合理？因爲任何介質到高度複雜的應用程序都包含大量配置（通過YAML或屬性文件）？驗證屬性或配置的單元/集成測試
即使底層庫或框架使用它們，許多這些配置也會導致運行時行爲。驗證配置在運行時是否正確使用是否明智？
一個支持參數是因爲沒有編譯器安全性，我們需要以某種方式驗證配置是否正確地規定行爲。
con的觀點是，我們是否驗證了底層框架的實現？
只測試配置文件可能不夠，因爲它不能保證配置是否能夠在運行時正確使用（可能存在拼寫錯誤或其他類似的錯誤）。
編號單元測試會告訴你什麼在測試工具中起作用，它與生產中的不同。
當你說你想驗證的配置時，你碰到了你的頭。測試和驗證是兩個完全不同的事情。如果您有辦法在生產環境中驗證運行時配置，它還將幫助您診斷運行時錯誤行爲。
有很多方法可以驗證運行時配置。最簡單也是最好的日誌記錄（例如「2016-09-24 10:13:00連接到http://my-configured-server.example.com以獲取用戶令牌」）。不要將配置轉儲到日誌文件 - 這不是端到端驗證 - 將配置詳細信息分散到日誌消息中。
配置問題通常是全有或全無;如果你沒有正確的配置，沒有任何反應，你不知道爲什麼。 （對於函數式編程尤其如此）。日誌記錄不僅可以告訴您配置是什麼，而且可以在什麼時候配置失敗。
還有其他巧妙的方法可以將配置細節分配到運行時。例如，將詳細的運行時詳細信息附加到錯誤消息中，特別是在電子郵件中，您有比日誌更多的空間。或者一個調試模式，可以將鼠標懸停在UI元素上，告訴您該元素的類和其他事實。
集成測試（當插接在一起的組件工作）和煙霧測試（一些完整的配置並正確的事情）可以important--如果部署，無需人工testing--我會說是必要的，但他們沒有替代運行時驗證。
取決於我們正在討論什麼樣的配置，在部署到生產環境後運行的自動化功能煙霧測試可以「間接」告訴您配置是正確的，因爲系統可以毫無錯誤地執行關鍵用例。 –
好點，毛利。測試應回答「你應該害怕什麼？」這個問題。如果您檢入版本控制的更改可能會觸發部署失敗，則需要找到一種測試方法 - 因爲您應該害怕這一點。如果您的部署過程中有人工步驟，某人（例如測試工程師）會立即注意到代碼無法運行，那麼添加煙霧測試是可選的，因爲您不得不擔心的最糟糕是尷尬。 –
這是非常合理的恕我直言，特別是在談論日益增長的虛擬化時。在之前參與的其中一個項目中，我參與了一個mSOA平臺，該平臺支持（當時）數百個網站，我們發現大部分問題都是由於
配置正確使用運行時
的Orchard recepies被搞砸了很多的時代，也是如此。所以一點Docker containers。測試基礎架構及其產品/服務使用的配置非常簡單。我已成功使用serverspec。
我只是在編寫一些東西，它有自己的屬性文件src \ test \ resources' ...不認爲它會給出太多的值來驗證，因爲運行時配置會不同 – vikingsteve