單元測試的一般思路

Question

這個問題可能有點模糊，但是這裏有。我剛開始進行單元測試，似乎正在爲基本概念掙扎。

我正在測試一個函數，檢查數據庫中是否存在記錄。如果不是，則添加新記錄並返回其ID。所以這個函數寫起來很簡單。我認爲測試它的唯一方法是通過使用模擬框架來檢查正確的屬性/方法被稱爲正確的次數。

我正在努力的部分是我所讀過的所有內容都是關於先編寫測試然後再編寫函數的。但是我覺得如果我先寫函數，然後編寫反映函數內部運作的測試，它纔會起作用。

這真的有一個金科玉律嗎？

無論如何我應該測試基本事務邏輯多少？

Answer 1

也許如果你想在這個水平上發展，你可以先寫方法合同，然後再根據合同寫測試。 您的方法的行爲與合同中定義的行爲很重要，因爲這是其他開發人員所期望的。 尤其應該測試邊緣情況（例外等）。

如果您打算在開發該方法的同時更改合同，那麼這並不好。因爲你沒有計劃好你的軟件，所以你可以重寫你的測試=）

測試很重要，因爲當你做代碼修改時，你以後可以用保存的測試更容易地檢測錯誤，當你通過嘗試開發新的東西來搗碎某些東西。

Answer 2

據我所知，我會說你應該時刻記住你將如何測試函數，但是首先要編寫函數本身。這將允許您找到可能發生的關鍵部分和最終的錯誤。 您還可以測試您的功能的輸出/輸入，並確保它們符合所需的結果 - 黑盒測試適用於此預編碼單元測試。

在編寫實際的方法之前，我也一直在努力寫這個單元測試的想法。請記住，我只是一名學生，這只是我的看法。

希望它能幫助，希望我是對的:)

Answer 3

我與掙扎的部分是，無論我曾經讀到，然後再編寫測試函數會談。但是我覺得只有我先寫函數然後編寫反映函數內部工作的測試才能工作。

聽起來好像你患了test-driven development（TDD）常見的雞/蛋問題。除非您在編寫代碼之前編寫測試，否則在知道代碼之前您不知道要測試什麼，並且您認爲不能執行TDD。

這真的是一個設計師的塊（tm）的情況。就像作者的封鎖一樣，通過編碼完成這項工作通常是很好的 - 即使你把所有的代碼都扔掉了。

破解原型，然後假裝它不存在。（不要運送:)這個原型應該探索你不熟悉的概念，或者沒有足夠的信息來開始設計。它應該讓你熟悉這個問題，以便你可以開始設計。

當你有了一個概念驗證，代碼審查了它。在你的評論中，確定你想讓公共接口看起來像什麼，哪些架構模式最適合該程序，哪些依賴應該彼此隔離（並在測試中被嘲笑）。做筆記，或在項目計劃軟件/項目跟蹤軟件中的工作項目中提交需求。

如果您在評論中發現了這些問題，您應該嘗試招聘其他程序員（以及可能設計人員/識別您業務需求的人員）來幫助您完成此項任務。代碼導師可能是個好主意。

從該評論，你應該能夠開始編碼你的測試。或者你可以開始寫技術規範 - 這個建議同樣適用於兩者。

（如果你工作在一個團隊中，收集需求和獲取用戶反饋/執行UATs還要求，但可能是別人的工作）

編輯

請記住，這只是解決這個問題的一種方法。另一種方法是簡單地放鬆任何TDD應該如何工作的清教徒般的理想，並簡單地開發與代碼並行的測試。同時檢查它們。

在沒有TDD的情況下進行單元測試也很好。單元測試賦予更多的好處，而不僅僅是編碼你的設計和需求。當您添加新功能或修復錯誤（迴歸測試）或移植代碼時，它們也是巨大的幫助。

Answer 4

不管怎樣，我應該測試基本事務邏輯多少？

這是我的經驗，你寫的測試越多，你就會越開心。

測試基本的事務邏輯將爲您提供關於您的類以及它們如何互操作的經驗，並讓您瞭解它們的速度以及基本事務邏輯的真實工作方式。

這會幫助你在編寫測試用例方面變得更好，因爲練習是完美的。

稍後，誰知道，它將幫助您在升級數據庫或完全更改數據庫時檢測到錯誤。

Answer 5

有對先寫測試很好的理由：

1. 你確保你的實際測試失敗。如果你先寫實現，然後再測試，測試會通過，但是你不知道它是否真的有效。測試中可能有錯誤！如果你先寫測試，你可以運行它，並確保它失敗。
2. 如果您只編寫通過測試所需的代碼，您將獲得非常高的代碼覆蓋率。
3. 如果您首先編寫測試，包括所有需要的嘲笑和假冒，您可以更好地理解需求。當嘲笑某個API時，您可能會發現有一些額外的信息需要您進行API調用或類似的事情。
4. 動機。如果你的代碼已經寫好了，那就太簡單了，只需要去Naaah，我不需要測試全部吧。錯誤。如果你反過來，這仍然是可能的，但它的抑制閾值更高。

總的來說，它可以感覺很難，但獎勵是值得的。

Answer 6

我會特別試着回答你關於測試基本事務邏輯的問題。大多數情況下，我爲層次結構中的較高單位編寫單元測試。例如，在基本模型 - 視圖 - 控制器設置中，我的單元測試正在測試控制器，而不是基礎DAL。爲什麼？因爲我假定，當一個控制器通過測試時，控制器下面的層也可以正常工作。

雖然對共享庫有一個例外。許多項目共享的庫將獲得他們自己的單元測試，例如，以確保API的穩定性。

另外，看看你的單元測試作爲項目中的另一個應用程序。確保你在測試中不使用c/p代碼，不要把一堆測試裝置放在一起，而是花時間設計一個可擴展的好結構。它會爲您節省很多時間。