如何對線程代碼進行單元測試？到目前為止，我已經避免了測試多線程代碼的噩夢，因為它看起來太像雷區了。我想問人們是如何進行依賴線程成功執行的代碼測試的，或者人們是如何測試那些只在兩個線程以給定方式交互時才會出現的問題的呢？對于今天的程序員來說，這似乎是一個非常關鍵的問題，把我們的知識集中在這個IMHO上是很有用的。
3 回答
嚕嚕噠
TA貢獻1784條經驗 獲得超7個贊
largeQ
TA貢獻2039條經驗 獲得超8個贊
這個問題發布的時候已經有一段時間了，但還是沒有答案.
有一種方法，我練習C#代碼。對于單元測試，您應該能夠編程。可復制測試，這是多線程代碼中最大的挑戰。因此，我的答案是將異步代碼強制放入測試工具中，這是可行的。同步.
這是Gerard Meszardos的書中的一個想法“xUnit測試模式并且被稱為“謙卑對象”(第695頁)：您必須分離核心邏輯代碼和任何聞起來像異步代碼的代碼。
這使您可以在同步方式，道路。您對在核心邏輯上執行的呼叫的時間有絕對的控制，因此可以進行可復制測試。這是分離核心邏輯和異步邏輯的好處。
這個核心邏輯需要由另一個類包裝，它負責異步地接收對核心邏輯的調用。代表們這些對核心邏輯的調用。生產代碼只能通過該類訪問核心邏輯。因為這個類只應該委托調用，所以它是一個非常“愚蠢”的類，沒有太多的邏輯。因此，您可以將這個異步工作類的單元測試保持在最低限度。
以上的任何東西(測試類之間的交互)都是組件測試。同樣在這種情況下，如果你堅持“謙遜對象”模式，你應該能夠對時間有絕對的控制。
慕姐4208626
TA貢獻1852條經驗 獲得超7個贊
真厲害！在我的(C+)單元測試中，我按照所使用的并發模式將其分解為幾個類別：
對于在單個線程中操作的類的單元測試，而不是線程感知的類-簡單，像往常一樣進行測試。
單元測試監視對象(那些在調用者的控制線程中執行同步方法的方法)，這些方法公開了同步的公共API-實例化了執行API的多個模擬線程。構造執行被動對象內部條件的方案。包括一個更長時間運行的測試，它可以在很長一段時間內從多個線程中擺脫出來。這是不科學的，我知道，但它確實建立了信心。
單元測試活動對象(封裝自己的線程或控制線程的線程)-類似于上面的#2，根據類設計的不同而有所變化。公共API可能阻塞或非阻塞，呼叫者可能獲得期貨，數據可能到達隊列或需要去排隊。這里有很多種組合；白色的盒子離開了。仍然需要多個模擬線程來調用被測試對象。
作為旁白：
在我所做的內部開發人員培訓中，我教并發支柱這兩種模式作為思考和分解并發問題的主要框架。顯然還有更高級的概念存在，但我發現這套基礎知識可以幫助工程師遠離困境。它還導致代碼更易于測試，如上文所述。
添加回答
舉報
0/150
提交
取消