我有一種情況,我需要單元測試一些需要預先初始化非常大的集合的場景,但預先初始化的數據需要硬編碼才能使單元測試正常工作。大型收藏單元測試 - 您如何最好地處理這些情況?
這種事情有沒有典型的做法?或者你們大多數人在每個單元測試中做出一個笨重的變量並使用它?我一直很好奇其他開發人員如何處理這種情況..
我有一種情況,我需要單元測試一些需要預先初始化非常大的集合的場景,但預先初始化的數據需要硬編碼才能使單元測試正常工作。大型收藏單元測試 - 您如何最好地處理這些情況?
這種事情有沒有典型的做法?或者你們大多數人在每個單元測試中做出一個笨重的變量並使用它?我一直很好奇其他開發人員如何處理這種情況..
如果這個數據是在很多不同的測試中使用的,那麼我們使用一個靜態容器來保存數據(假設數據沒有更改)。然後測試可以在需要時引用它。
如果數據是特定於夾具的,那麼它只是夾具的一部分,以便縮小範圍。
對於其他數據部分,我們可以使用模擬/存根技術來公開測試數據。我們的很多數據都是通過我們的DAL接口發佈的,甚至是靜態的東西,所以我們通過我們使用的普通接口方法爲接口提供了靜態數據的測試實現。我們的很多測試都是使用這個存根建立的。
我們將此與SpecFlow結合使用。我們可以定義送入DAL存根的Background:
表,然後在我們的測試代碼使用DAL接口與數據進行通信時注入此DAL。對於大量的靜態數據,我們只需對其進行硬編碼或將其編碼到DAL存根可根據請求獲取的區域。
當然,這不一定是你應該怎麼做的。這正是我所看到的處理方式。
但前期初始化的數據需要被硬編碼爲單元測試 工作
在我看來,沒有什麼不對的,需要一組數據,以測試證明輸出。我們混合了真正的單元測試,其中外部事物是分開的,我們只測試一個有問題的方法,但是隨後使用SpecFlow,我們有了一些「用例」測試,我們在更廣的範圍內測試事物。但是,這仍然需要定義的輸入。
要保持控制的一件重要事情是單元測試應儘可能分開。 Fixtures允許您將範圍擴展到一小部分測試,但是如果您發現自己有大量可能會在多次測試中使用的備份數據 - 您需要退後一步。
我們最近有一個配置操作的靜態列表不是不可變的。進行更改後,測試會在更改後運行。我們確定了這一點並加以糾正,但這並非微不足道。