第十次讀書筆記 軟件工程：方法與實踐

單元測試

咱們在開發的過程當中應該實時的對新產生的代碼進行測試，一是爲了及時發現問題及時更改，避免往後代碼複雜龐大，debug工做難度會指數級上升，這樣及時測試，縮小了bug範圍，能快速找到問題關鍵，避免沒必要要的時間浪費；不斷的發現問題，多是是本身編寫代碼前邏輯關係的錯誤，這種致命的錯誤越早發現，越早改正，越早走上正軌，還能幫助本身更好的理解總體的框架內容，邏輯結構。

單元測試應該由軟件開發人員進行，而不是專門的測試團隊。本身開發的代碼，本身內心清楚內部的處理是怎麼進行的，換另外一我的測試會大大下降測試效率。更加廣義的測試不只僅是測試漏洞的所在，還能夠是測試代碼的運行效果，而且進行一些修改、優化、更正，這些顯然不是另外一個專門的測試人員能夠輕鬆作到了。那麼，如上所述能夠清晰的看到，代碼一經編寫，就要及時測試，因此單元測試與代碼的編寫是一體的，能夠看做是軟件構架的一部分。

單元測試應儘量的採起自動化的方式。單元測試應該和代碼修改同步，頻繁執行。以開發人員手工測試的時間成本和精力成本是巨大的。那麼自動化的測試能夠大大減輕開發人員的負擔，還能夠增長測試的頻率。可是這一步我尚未學到什麼方法能夠作到這一點，除了用一些集成功能強大的IDE能夠自動檢查一些基礎的bug其餘都仍是隻能開本身手動檢查。

所謂單元、單元，確定是要將代碼隔離分開進行測試。那麼怎麼隔離就是一個首先要想到的問題。回憶結對編程的過程，就是要在編寫代碼的時候有很清晰的邏輯層次，調用層次，將整個代碼框架方塊化模塊化，那麼對於每個模塊就是一個個較爲獨立的單元，優先編寫下層代碼，測試下層單元，而後再寫上層的代碼，上層代碼不免會必須調用下層代碼，但這時下層代碼已經被檢查測試過不會是bug的發生點，貫徹了單元測試的優點（快速找到問題所在）與意義（實時檢查），如若下層代碼未編寫完成，那麼先編寫的上層代碼就沒辦法很好地檢查測試，堆積問題，這樣就違背了單元測試的初衷。

自動化單元測試框架

自動化單元測試框架通常都須要提供的功能有：（1）方便地編寫測試用例，並清晰地聲明指望的測試結果；（2）運行測試用例，檢查測試用例的運行結果併產生報告；（3）對測試用按照必定的規則進行組織。測試廣泛所用的框架有：JUnit、NUnit、cppUTest。使用了統一的某幾個框架可使全部人編寫測試代碼時統一風格，保持一致性；同時確定能夠提升測試的開發效率。

測試單元代碼也是代碼，要簡單，全面地檢查到各類狀況。測試代碼也要遵循編寫代碼的一些要求：可理解性，可維護性等等。每個測試代碼的編寫都應該遵循創建——執行——驗證——拆卸四個步驟。

創建階段：所謂創建階段是指測試代碼創建被測試代碼的前置條件，使得被測試單元爲測試作好準備；

執行階段：測試代碼調用被測單元接口；

驗證階段：測試代碼經過斷言肯定是否得到預期的結果，從而判斷被測試代碼的正確性；

拆卸階段：測試代碼，將被測目標及環境恢復到測試前的初始狀態，以免影響後續的測試。