單元測試建議

我有一箇中等到高度複雜的應用程序，由大約50-60個表的大型數據庫支持。我試圖在代碼上獲得儘可能多的單元測試覆蓋率，但我真的在嘲笑數據集和一些關鍵概念。我實際上對試圖實現全面單元測試覆蓋率的想法感到焦慮，因爲我不知道如何執行以下操作：單元測試建議

1）測試每種功能的每種可能場景和數據組合。 I.E.我們的一個函數返回基於約20個輸入的值，每個輸入具有3個不同的可能值。一個人怎麼可能測試所有的值呢？如果我可以測試所有這些組合，我將不得不在測試中編寫完全相同的邏輯代碼，以確定它是否應該通過（不是多餘的？）。

2）數據和結果隨時間變化！例如，如果我針對上週租用汽車的員工人數進行查詢，隨着時間的推移，我會一直返回不同的結果。我如何編寫一個單元測試，知道如果結果每天都會變化，會有多少結果？

人們說，如果你正在爲單元測試掙扎，你做錯了，所以請賜教我如何最好地處理這些情況。

來源

2014-09-30 Ray Suelzer

我很欣賞投票。如果有理由，我會更加感激。我很想知道什麼是單元測試變量的最佳實踐，這些變量隨時間而變化並且有可能的輸入。 – 2014-09-30 03:03:42

原因是沒有具體的問題。你基本上要求「單元測試建議」，你可以通過一個簡單的谷歌搜索找到（儘管我建議特別尋找BDD建議）。換句話說：你有什麼具體問題，你有什麼嘗試？ – 2014-09-30 03:08:49

1）測試邊緣案例;並希望使用允許「數據驅動」測試的測試框架。 2）測試結果不應隨時間而改變，只能是數據。接受此類測試的時間參數（現在只是數據）*和*使用DI/IoC獲取時間對象，以便在測試中對其進行模擬！查詢的測試數據庫也應該不變（對於預期的數據/結果）。 – user2864740 2014-09-30 03:13:04

我儘管如上所述評論，這裏有一些想法：

在單元測試你測試「單位」。單元測試的很大一部分精力在於確定一個「單元」到底是什麼。那麼你的單位是什麼？提示：他們幾乎從不涉及數據庫。
確定正確的單位是防止結果和數據變化的問題。如果核心功能發生變化，那麼單元測試需要修改甚至刪除，否則應該是最少的維護。
組合和排列 - 測試你實際需要測試的東西。你可以爲此寫一些幫手代碼。然而，你並不總是需要來測試絕對的一切，測試的重點是有用的，沒有進一步的。
我發現高水平的測試有用，但你可能不會。您在單元測試方面的經驗和能力會影響測試的實用性。

來源

2014-09-30 03:16:40

謝謝。我最近閱讀的其中一篇文章建議首先測試一些邊緣案例，然後在生產中出現任何錯誤以將其添加回單元測試。我需要有一些數據來測試我的方法，這就是爲什麼我有測試數據。我不是單元測試實際的查詢生成，只是方法返回正確的東西。 – 2014-09-30 03:21:58

@RaySülzer數據庫通常被認爲是外部系統，因此不屬於「單位」。通常在這種情況下，您可以將數據作爲參數傳遞，也可以將數據源作爲接口並存根。將20個參數寫入方法是一個可怕的想法，儘管部分原因在於您陳述的原因。他們無法控制計算的所有相同方面。我鼓勵你把它分開。 Joshua Bloch建議方法中不要超過四個參數。 – 2014-09-30 03:35:02

這不是20個參數persay，該方法接受類「Employee」的單個對象，該對象上有一堆屬性。然後這個方法調用一些私有方法傳遞屬性，根據值返回一個布爾值。我將通過傳遞他們需要的一個或兩個參數來單元測試私有方法，而不是單元測試公共方法。 – 2014-09-30 04:49:48

單元測試建議

回答

相關問題