前言
看到標題你可能會問為什么這一篇會談到代碼測試，不是說代碼優化么？前兩篇主要是講了程序的輸出及Log4j的使用，Log能夠幫助我們進行bug的定位，優化開發流程，而代碼測試有什么用呢？其實測試是為了驗證自己所編寫的代碼，及時排除錯誤，減少bug，所以我認為，減少錯誤也是優化的一個方案體現，而且如果進行了合理的單元測試，也可以幫助優化開發流程，一旦出現問題，使得bug的定位過程更加迅速。
你願意進行單元測試嗎？
其實，像第一篇文章所說的，對於打印輸出信息，我們更習慣於使用System.out命令，所以很多時候，習慣決定了我們的編碼方式，那么你習慣於做單元測試嗎？
我感覺很多人可能都不是很樂忠於在開發工作做這件事，因為主觀意識中會覺得這是一件"麻煩"的事情，或者說效果不是很明顯的一件事。
針對於此，我也粗略的整理了一下根由，對各個原因，也分別談一下自己的想法，當然，都是個人看法，大家覺得有用就看，覺得無用忽略即可。
- 開發項目時並沒有明確的要求我去寫單元測試。
因為沒人要求，所以就不寫單元測試。我認為作為一個技術人員，應該關注自我增值和技術上的提升，要求應該是自己提給自己的，並不是說項目沒有要求或者沒人督促我們就不去做一些事情了，這種裝鴕鳥式的態度和鑽空子的小聰明不值得提倡，我們不僅要對項目負責，其實更多的也是對自己負責，嚴格要求自己，多學習，才能更快的進步，不要隨波逐流，不要進入其他人的節奏中。
- 業務邏輯比較簡單不值得編寫單元測試。
這又是一個理由，而這個理由的深層次的原因，應該是來源於對自己的自信，自信是件好事，但是要掌握好其中的度。相對於機器來說，擁有主觀意識的人類更容易犯一些錯誤，錯誤可能不大，或者是一些低級錯誤，比如忘記寫一個分號、忘記判空、忘記類型轉換...這些都是小錯誤，但是不注意的話就會出現bug，然后再去花時間修修補補。
所謂的業務邏輯比較簡單，其實是相對的。當你對某一塊業務邏輯很熟悉的時候，你自然會認為它很簡單。然而，單元測試的必要性並不是僅僅在於測試代碼的功能是否正確，還在於，當其他同事在了解你的業務的時候，能夠很快的通過單元測試來熟悉代碼的功能，甚至不用去讀代碼，就能夠知道它做了哪些事情。因此，寫單元測試不僅是解放了自己，更方便了別人。
- 做了少量的單元測試。
這里可能有幾方面的原因：
1、為了完成編碼任務，沒有足夠的時間編寫單元測試。
2、在項目的前期還是盡量去編寫單元測試，但是越到項目的后期就越失控。
3、和上一個原因類似，對自己足夠自信，於是只挑一小部分進行單元測試。
我們簡單的梳理一下開發過程，開發過程：需求—>編碼—>自測—>預發布—>測試—>回滾—>改bug—>發布—>發現bug—>改bug—>發布……我們可以觀察到，整個過程中改bug出現了很多次，它與編碼工作一樣，都是開發過程中不可缺少的一部分，編碼只是整個開發過程中的一部分，開發不僅僅是編碼而已。
編碼的完工≠項目的完工。
因為自測的不完備，導致預發布過程或者后期的冒煙測試難度加大，加長回滾和bug修復過程，這是一個自相矛盾的事情。
- 測試人員會抓住所有的bug，用不着進行單元測試。
也會有人把鍋丟給測試，可能存在這樣一個觀點，既然有測試了，干嘛還要我費那么多精力去寫測試用例？
但是測試工程師往往不在意代碼層面，其測試工作只是業務上的集成測試，也就是我們熟知的黑盒測試，更多的是進行功能測試，對代碼中單個方法是沒有辦法進行測試的，因此，測試出的bug的范圍也會很廣，根本不能確定bug的范圍及發生的原因，所以問題的定位及bug產生的原因，還得去花一些時間來確認，如果已經進行了自測，知道了哪部分代碼是健康的，至少可以縮小檢查的范圍，減少定位bug所花的時間。而且，單元測試也就是順手的一件事，雖然不能解決百分百的麻煩，但是給各方人員提供的便利也是很多的。
- 不會寫。
想當初剛進入這個行業，我壓根兒不知道這個事情，也根本沒有單元測試的概念，因為那時候我連開發工作都做的不是很好，更不要提過程優化了，直到一段時間后，熟悉了開發流程，可以把開發做好的時候，才開始慢慢接觸流程優化，但是一開始碰到的問題就是，我不會。
其實網上教程也是很多的，下一篇會進行簡單的介紹和教程，代碼也會放到github中，不會可以學，但是不做的話就有些不負責任了。
代碼測試的重要性及必要性
測試常常是程序員十分厭倦的一個事情。測試能給我們帶來什么？了解這些是非常重要的，測試不可能保證一個程序是完全正確的，但是測試卻可以增強我們對程序完整的信心，測試可以讓我們相信程序做了我們期望它做的事情。測試能夠使我們盡早的發現程序的bug和不足。
當然，我們主要討論的是單元測試。單元測試是一個方法層面上的測試，也是最細粒度的測試。用於測試一個類的每一個方法都已經滿足了方法的功能要求。在開發中，對於自己開發的模塊，只有在通過單元測試之后，才能提交到SVN庫或者Git 庫。
再一次強調，你不是一個人，你的代碼有問題，同事pull下來的代碼也是有問題的，浪費大家的時間。對於這件事情，我是深有感觸的，在去年的一次項目開發過程中，由於我沒有做好代碼審查和單元測試匆匆上傳到代碼庫，導致其他開發人員也無法正常開展工作，還要幫着我去修改bug，這件事導致我有些自責，也在后續的開發工作中更認真，更專注，雖然偶爾也會犯錯，但是在態度上不再吊兒郎當、無關痛癢，代碼測試有時候也能體現出一個人的態度問題。
知道測試的重要性最好，只要寫就是對項目和編碼認真的體現，雖然一開始可能寫的不是很好很完善，邁出第一步就是正確的，隨着測試編碼的增多，測試用例也會逐漸完善，關鍵是要明確和認識到單元測試的重要性。
最終目的
前面論述了一下單元測試難以推進的原因以及單元測試的重要性，當我們開始認真的去做這件事了，我們也要做好這件事，我們想要追求的是完美，即使無法十全十美，也要盡自己的全力去爭取寫出漂亮的代碼，漂亮指得是易讀、簡潔、健壯，為了達到這個目的，我們就需要做覆蓋率高以及更完善的單元測試。
測試的覆蓋率和完備性越高對於項目來說就越是一個利好的信號，即使做了單元測試，但是較為懶散，隨隨便便寫了幾個測試用例，這不能算得上單元測試，這種行為不僅是對項目不負責任，也是對自己不負責任。
不能和不為區別是很大的，不能代表的就是你沒有能力去做到一件事，而不為則是明明能做到卻不做。對於不能，那么首先要做的，就是通過自己的努力和學習將不能變為能，可能現在項目中並沒有做單元測試，原因是因為不會，那就要學習如何去進行單元測試，掌握這個技能。
結語
認真些，端正自己的態度，做好自己的單元測試。
(怎么感覺說出這些話的我這么正氣凜然，我不像是個剛正不阿的五道杠青年啊，哈哈哈哈哈。)