談談單元測試之（一）：為什麼要進行煩人的單元測試？
阿新 • • 發佈：2018-12-20
前言
最近，在網上看到過一個調查，調查的內容是“程式設計師在專案開發中編寫單元測試的情況”。當然，至於調查的結果，我想聰明的你已經可以猜到了。高達 58.3% 的比例，一般情況下不寫單元測試，只有偶爾的情況才會寫寫。16.6% 的程式設計師從來都不寫單元測試。只有很少的一部分程式設計師才會在自己的程式碼中進行單元測試，並保證方法測試通過。看到這些，你想到了什麼？
現狀
雖然，這個調查可能會有些片面性，但這也基本反應了國內程式設計師的開發現狀，很少有程式設計師能夠比較認真的去編寫單元測試。而且，甚至有的程式設計師根本就不知道為什麼要寫單元測試（這一點讓我很鬱悶）。他們經常會說，公司裡不是有測試人員嘛，測試應該是他們要做的事，我們的工作只是開發（這位仁兄肯定沒有學過軟體工程）。當然，這些並不是偶然的，正如佛經裡邊說的“因果迴圈”，有果必有因。那麼，到底是什麼原因，導致程式設計師對單元測試這麼不感冒呢？
通過與幾個朋友的討論，以及網上的調查，主要有這幾種原因，導致程式設計師對單元測試很排斥，或許說很不以為意。
- 不知道怎麼編寫單元測試
- 專案沒有要求，所以不編寫
- 單元測試價值不高，完全是浪費時間
- 業務邏輯比較簡單，不值得編寫單元測試
- 不管怎樣，整合測試將會抓住所有的 bug，用不著進行單元測試
- 在專案的前期還是儘量去編寫單元測試，但是越到專案的後期就越失控
- 為了完成編碼任務，沒有足夠的時間編寫單元測試。編寫單元測試會導致不能按時完成編碼任務，導致專案延期
不知道怎麼編寫單元測試
這個問題在於，還沒有接觸過單元測試，同時，也沒有體會過企業級的程式碼開發。不知道同時也不瞭解單元測試能帶給你什麼。設想一下，當你開發完一個功能模組的時候，你如何確定你的模組沒有 bug 呢？如果涉及到具體的業務，你會執行 debug 模式，然後一點一點的深入到程式碼中去檢視嗎？如果你一直都是這樣，那麼你早就已經 OUT 了。趕快去了解一下單元測試的工具吧，你會收穫很大的。
專案沒有要求，所以不編寫
這個問題反映出了一種現象，同時也是一種習慣。專案有沒有要求，只能說明專案的管理上不嚴格，並不是程式設計師不編寫單元測試的理由。他們在以往的開發中，並沒有養成寫單元測試的好習慣。可想而知，他們的程式碼質量，我就不敢恭維了。給個建議，嘗試著寫漂亮的程式碼，之所以因為漂亮，是指得健康、簡潔、健壯。當然，完成漂亮的程式碼就離不開單元測試了。
單元測試價值不高，完全是浪費時間
這種說法其實是錯誤的。為什麼這麼說呢？在日常的開發中，程式碼的完工其實並不等於開發的完工。如果沒有單元測試，那麼如何保證程式碼能夠正常執行呢？測試人員做的只是業務上的整合測試，也就是黑盒測試，對單個的方法是沒有辦法測試的，而且，測試出的 bug 的範圍也會很廣，根本不能確定 bug 的範圍，還得去花時間來確定 bug 出在什麼地方。難道這就不浪費時間了嗎？甚至，這樣的方式，時間浪費的會更多。
業務邏輯比較簡單，不值得編寫單元測試
所謂的業務邏輯比較簡單，其實是相對的。當你對某一塊業務邏輯很熟悉的時候，你自然會認為它很簡單。然而，單元測試的必要性並不是僅僅在於測試程式碼的功能是否正確，還在於，當其他同事在瞭解你的業務的時候，能夠很快的通過單元測試來熟悉程式碼的功能，甚至不用去讀程式碼，就能夠知道它做了哪些事情。因此，寫單元測試不僅是解放了自己，更方便了別人。
專案前期還在儘量寫測試，到了後期就失控了
這種問題的原因在於，對專案進度、專案中的技術點研究時間、人員的溝通、業務需求的熟悉程度等沒有把控好。這個問題的出現並不是個人的問題，而是反映了專案管理中存在的問題。當然，個人的原因也存在，就是如何在有限的時間裡，提高效率。這一點需要大家好好思考一下了。我的建議，多做計劃，根據實際情況變更計劃。多和專案組長、組成員進行溝通。及時反應專案中存在的問題。
為了完成編碼任務，沒有足夠的時間編寫單元測試
這個問題在於，程式設計師領取的任務較為複雜，或者自己的開發效率有待提高。其實，開發任務是包括編碼和單元測試的。在領任務的時候，應該跟據自身的能力，跟組長或經理溝通好，以便留出一定的測試時間。當然，提高自己的編碼效率也是很有必要的。至於如何提高開發效率，網上有很多這樣的文章，這裡就不再贅述了。
重要性
測試常常是程式設計師十分厭倦的一個活動。測試能給我們帶來什麼？瞭解這些是非常重要的，測試不可能保證一個程式是完全正確的，但是測試卻可以增強我們對程式完整的信心，測試可以讓我們相信程式做了我麼期望它做的事情。測試能夠使我們儘早的發現程式的 bug 和不足。
一個 bug 被隱藏的時間越長，修復這個 bug 的代價就越大。在《快速軟體開發》一書中已引用了大量的研究資料指出：最後才修改一個 bug 的代價是在 bug 產生時修改它的代價的10倍。
當然，我們主要討論的是單元測試。單元測試是一個方法層面上的測試，也是最細粒度的測試。用於測試一個類的每一個方法都已經滿足了方法的功能要求。在開發中，對於自己開發的模組，只有在通過單元測試之後，才能提交到 SVN 庫 或者 Git 庫。
應用
正是由於測試在開發中的重要地位，才會在IT界颳起了 TDD 的旋風。TDD，也就是測試驅動開發模式。它旨在強調在開發功能程式碼之前，先編寫測試程式碼。也就是說在明確要開發某個功能後，首先思考如何對這個功能進行測試，並完成測試程式碼的編寫，然後編寫相關的程式碼滿足這些測試用例。然後迴圈進行新增其他功能，直到完成全部功能的開發。
工具
說了這麼多，那麼都有什麼工具（框架）能幫助我們完成可重複的單元測試呢？下面我就介紹幾個常用的。這裡只介紹 Java 語言的。其他語言的請問谷老師（Google）。
- JUnit（推薦使用JUnit4）
- TestNG
這裡僅僅是介紹一下有哪些最常用的 Java 單元測試工具，對於如何使用這些工具，在後續的部落格中會有介紹，這裡就不再多說了。有興趣的請關注後續的文章。
結束語
俗話說，一屋不掃，何以掃天下。開發中，我們自己的程式碼都不能保證功能的正確性，那麼還有什麼效率可言呢？做再多的任務，寫再多的程式碼也只不過是在搭雞窩，做著機器一樣的重複的工作。IT界有一個原則，DRY原則 —— Don’t Repeat Yourself ！只有通過對自己的工作不斷的檢查，不斷的測試，才能不斷的突破，不斷的脫穎而出，當然，你才能不斷的提高。
Test Day Day Up！ Experience Day Day Up！ And Money Day Day Up Too！
哎呀媽呀，中國式英語又出來了！
原創連線：http://blog.csdn.net/happylee6688/article/details/37962283#insertcode