建構之法閱讀筆記03

    單元測試對代碼品質的影響

    1.（過去的做法）

    記得大一大二寫程式的時候，從來都不寫單元測試，現在去分析當時的心理，可能出于三個原因。第一，當時寫代碼的水準非常low，當然現在也挺low的，不過現在是大三了，更何況在上《軟體工程》，編寫代碼的水準較以前肯定會有很大的提高。大一大二的時候，可能當時老師布置下任務以後，等到老師檢查的時候差不多才剛剛把任務完成，來不及寫單元測試就需要向老師展示結果了，這是第一個原因。第二個原因則是不敢寫單元測試，以前寫程式的時候往往用一組特殊的資料去驗證程式的正确性，隻要這組資料能讓程式得到正确的結果，那就代表自己寫的這個程式過關了，從未想過多用幾組資料去測試一下，也不敢用别的資料去測試，因為一換資料就有可能導緻程式出錯，正是這種害怕程式出錯的心理，讓我的程式設計水準在很長的一段時間内都處于一個停滞不前的狀态。第三個原因則是不會寫單元測試，過去老師對我們的要求就是能實作程式應有的功能，所謂的測試也就隻是多用幾組資料去測試一下程式的結果，從來不會單獨的寫一個小程式從多方面的角度去驗證程式。    

    是以，真正學習了單元測試并在實際的程式設計中使用單元測試時，才發現，單元測試是保證代碼品質的有效手段。所謂的單元測試其實就是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明确的功能是否正确。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。執行單元測試，是為了證明某段代碼的行為确實和開發者所期望的一緻，使用單元測試這個簡單有效的技術就是為了令代碼變得更加完美。除了我上述所說的三個原因外，程式設計者不喜歡寫單元測試還有很多的“理由”：編寫單元測試太花時間了、運作測試的時間太長了、我并不清楚代碼的行為，是以也就無從測試、這些代碼都能夠編譯通過等等。其實這些理由都是一些借口，當我們真正走向工作崗位以後，寫單元測試是必不可少的工作，其實寫好單元測試可以有效的提高代碼的品質，在對工程整合時，子產品代碼的品質才不會在整個工程中有太大的問題。

    2.（不寫單元測試的壞處）

    就普通的程式員來講，平均每十行代碼就會存在一個Bug，這也就意味着程式員在程式設計式時存在Bug是在所難免的。寫單元測試就是對一個小子產品或者一個小功能的測試，這個小子產品在寫之前我們就明确了它要完成什麼功能，是以單元測試就是一個提前找Bug的過程。在實際的工作中，一個個的大工程都是由不同的程式設計人員編寫一個個小的子產品或者小的功能，最終将這些子產品整合到一起，形成一個完整的項目。如果在編寫完一個較小的子產品後不寫單元測試，可能這一個小的子產品在單獨運作時功能實作比較好，但是當将其整合到整個工程中時就有可能出現大量的Bug，這些Bug出現的原因有很多種，可能是某種條件沒有考慮進去導緻了功能的缺陷，也有可能是與别的子產品存在沖突等等。總之，不寫單元測試，程式的品質就沒法得到很好的保障。

    3.（改進的辦法）

    對于程式子產品寫單元測試時，常用的方法有Right-BICEP原則。Right-BICEP原則其實是對程式測試時比較重要的6個部位，第一個單詞Right，是指要用多組資料去測試程式能否得到正确的結果，第二個字母B是指程式所有的邊界條件是否都能夠得到正确的處理，第三個字母I是指能否檢查程式的反向關聯，第四個字母C是指程式在交叉檢查時是否仍然能夠得到正确結果，第五個字母E是指能否強制程式錯誤條件的發生，最後一個字母P則是指程式是否滿足了功能的需求。Right-BICEP測試原則是當下比較常用的測試方法，而且通過這6個方面的測試，程式的品質一般可以得到很好的保障，即使在對程式進行整合時仍有Bug存在，但是那時解決Bug也是比較容易的。

    從我們學生的角度講，雖然現在沒有公司的硬性規章制度在限制着我們，但是我們應該培養起寫單元測試的好習慣，寫單元測試一方面是為了得到高品質的代碼，另外，它可以鍛煉我們考慮問題的能力，在查找Bug修改Bug的過程中，我們可以把問題考慮的更加全面。除了要寫單元測試外，我們還要對單元測試的結果進行記錄統計，因為每個程式員由于自身程式設計習慣的不同，很多時候會犯相同的錯誤，通過對單元測試的結果進行記錄，我們可以統計出自己常犯的一些錯誤，在後期的程式設計中加以有目的的關注，我們便可以提高程式設計的效率和品質。