單元測試複雜邏輯

對於每個後置條件的測試與其他後置條件的測試非常相似的單元測試相對複雜的方法，最好的方法是什麼？前提條件很容易單獨進行測試，但是很多設置都會確保它們全部保留，以便測試後期條件。我想到的三種方法是：單元測試複雜邏輯

創建一個可以一次測試所有內容的通用函數，但默認爲最簡單的方案。該功能將採用標誌參數來指示與最簡單場景的偏差。然後，爲每個後置條件（或組合）創建一個單元測試，使用適當的標誌調用該函數以獲得該後置條件的覆蓋範圍。這樣做的好處是幾乎沒有代碼重複，所以如果被測代碼發生變化，只需要重寫一個測試函數;並且編寫測試以覆蓋後續條件組很簡單，但缺點是一般測試功能非常複雜
爲最簡單的方案進行單元測試，然後進行復制，粘貼和修改。好處是每個測試都非常簡單。缺點是原始測試的問題需要固定多少次，因爲它被粘貼。
編寫一個通用函數，允許通過將函數作爲參數來覆蓋各個位，但默認情況下會測試最簡單的方案。好處與帶有標誌的常規函數的好處類似，但我認爲將它們全部網格化在一起可能會更加複雜。

第四個選項是「你做錯了;將被測試的方法分解成比較容易測試的位！

任何想法？

2012-07-06 Don 01001100

我投了第四個選項。 – 2012-07-06 19:04:59

也許是第四種選擇。你評估過你的班級和方法，以確保你遵守單一責任原則嗎？ – EkoostikMartin 2012-07-06 19:10:33

感謝您的回覆。該類是一個業務邏輯類，我敢肯定有一個單一的責任（我沒有聽說過這個名稱），該方法是一個「保存」方法，它將傳輸對象與用戶數據被轉換成（可能是許多相互關聯的）域對象以便在數據存儲中保存。我將嘗試重構設置代碼以使其更加可重用。也許問題不在於被測試的方法是複雜的，而是我沒有一種簡單且可重用的方式來設置測試。 – 2012-07-06 20:01:29

我剛纔的評論有些激動。

從實質上來說，我實際上會主張做的是做爲選項2列出的內容，然後重構測試代碼以消除由複製修改工作創建的重複。

一旦你完成了全部測試，你可能會尋找方法來重構生產代碼，將其分解成更小，更易於管理的部分，並使這些部分可重用。但在做出重大改變之前進行測試總是健康的。

來源

2012-07-06 21:46:04

感謝您的回答。這是我傾向於遵循的方向。 – 2012-07-09 17:43:50

單元測試複雜邏輯

回答

相關問題