<h1>日常啰嗦</h1>
看到標題你可能會問為什么這一篇會談到代碼測試纵揍，不是說代碼優(yōu)化么？前兩篇主要是講了程序的輸出及Log4j的使用议街，Log能夠幫助我們進行bug的定位泽谨，優(yōu)化開發(fā)流程，而代碼測試有什么用呢？其實測試是為了驗證自己所編寫的代碼吧雹，及時排除錯誤骨杂，減少bug，所以我認為雄卷，減少錯誤也是優(yōu)化的一個方案體現(xiàn)搓蚪，而且如果進行了合理的單元測試，也可以幫助優(yōu)化開發(fā)流程丁鹉，一旦出現(xiàn)問題妒潭，使得bug的定位過程更加迅速。
<h1>你愿意進行單元測試嗎鳄炉？</h1>
其實杜耙，像第一篇文章所說的，對于打印輸出信息拂盯，我們更習慣于使用System.out命令佑女，所以很多時候，習慣決定了我們的編碼方式谈竿，那么你習慣于做單元測試嗎团驱？
我感覺很多人可能都不是很樂忠于在開發(fā)工作做這件事，因為主觀意識中會覺得這是一件"麻煩"的事情空凸，或者說效果不是很明顯的一件事嚎花。
針對于此，我也粗略的整理了一下根由呀洲，對各個原因紊选，也分別談一下自己的想法，當然道逗，都是個人看法兵罢，大家覺得有用就看，覺得無用忽略即可滓窍。
- 開發(fā)項目時并沒有明確的要求我去寫單元測試卖词。
因為沒人要求，所以就不寫單元測試吏夯。我認為作為一個技術(shù)人員此蜈，應該關(guān)注自我增值和技術(shù)上的提升，要求應該是自己提給自己的，并不是說項目沒有要求或者沒人督促我們就不去做一些事情了，這種裝鴕鳥式的態(tài)度和鉆空子的小聰明不值得提倡，我們不僅要對項目負責，其實更多的也是對自己負責蚓炬，嚴格要求自己，多學習白胀，才能更快的進步箱沦，不要隨波逐流陈醒，不要進入其他人的節(jié)奏中。
- 業(yè)務(wù)邏輯比較簡單不值得編寫單元測試瞧甩。
這又是一個理由钉跷，而這個理由的深層次的原因，應該是來源于對自己的自信肚逸，自信是件好事爷辙，但是要掌握好其中的度。相對于機器來說朦促，擁有主觀意識的人類更容易犯一些錯誤膝晾，錯誤可能不大，或者是一些低級錯誤务冕，比如忘記寫一個分號血当、忘記判空、忘記類型轉(zhuǎn)換...這些都是小錯誤禀忆，但是不注意的話就會出現(xiàn)bug臊旭，然后再去花時間修修補補。
所謂的業(yè)務(wù)邏輯比較簡單箩退，其實是相對的离熏。當你對某一塊業(yè)務(wù)邏輯很熟悉的時候，你自然會認為它很簡單戴涝。然而滋戳，單元測試的必要性并不是僅僅在于測試代碼的功能是否正確，還在于啥刻，當其他同事在了解你的業(yè)務(wù)的時候奸鸯，能夠很快的通過單元測試來熟悉代碼的功能，甚至不用去讀代碼郑什，就能夠知道它做了哪些事情府喳。因此，寫單元測試不僅是解放了自己蘑拯，更方便了別人钝满。
- 做了少量的單元測試。
這里可能有幾方面的原因：
1申窘、為了完成編碼任務(wù)弯蚜，沒有足夠的時間編寫單元測試。
2剃法、在項目的前期還是盡量去編寫單元測試碎捺，但是越到項目的后期就越失控。
3、和上一個原因類似收厨，對自己足夠自信晋柱，于是只挑一小部分進行單元測試。
我們簡單的梳理一下開發(fā)過程诵叁，開發(fā)過程：需求—>編碼—>自測—>預發(fā)布—>測試—>回滾—>改bug—>發(fā)布—>發(fā)現(xiàn)bug—>改bug—>發(fā)布……我們可以觀察到雁竞，整個過程中改bug出現(xiàn)了很多次，它與編碼工作一樣拧额，都是開發(fā)過程中不可缺少的一部分碑诉，編碼只是整個開發(fā)過程中的一部分，開發(fā)不僅僅是編碼而已侥锦。
編碼的完工≠項目的完工进栽。
因為自測的不完備，導致預發(fā)布過程或者后期的冒煙測試難度加大恭垦，加長回滾和bug修復過程快毛，這是一個自相矛盾的事情。
- 測試人員會抓住所有的bug署照，用不著進行單元測試祸泪。
也會有人把鍋丟給測試，可能存在這樣一個觀點建芙，既然有測試了没隘，干嘛還要我費那么多精力去寫測試用例？
但是測試工程師往往不在意代碼層面禁荸，其測試工作只是業(yè)務(wù)上的集成測試右蒲，也就是我們熟知的黑盒測試，更多的是進行功能測試赶熟，對代碼中單個方法是沒有辦法進行測試的瑰妄，因此，測試出的bug的范圍也會很廣映砖，根本不能確定bug的范圍及發(fā)生的原因间坐，所以問題的定位及bug產(chǎn)生的原因，還得去花一些時間來確認邑退，如果已經(jīng)進行了自測竹宋，知道了哪部分代碼是健康的，至少可以縮小檢查的范圍地技，減少定位bug所花的時間蜈七。而且，單元測試也就是順手的一件事莫矗，雖然不能解決百分百的麻煩飒硅，但是給各方人員提供的便利也是很多的砂缩。
- 不會寫。
想當初剛進入這個行業(yè)三娩，我壓根兒不知道這個事情庵芭，也根本沒有單元測試的概念，因為那時候我連開發(fā)工作都做的不是很好雀监，更不要提過程優(yōu)化了喳挑，直到一段時間后，熟悉了開發(fā)流程滔悉，可以把開發(fā)做好的時候，才開始慢慢接觸流程優(yōu)化单绑，但是一開始碰到的問題就是回官，我不會。
其實網(wǎng)上教程也是很多的搂橙，下一篇會進行簡單的介紹和教程歉提，代碼也會放到github中，不會可以學区转，但是不做的話就有些不負責任了苔巨。
<h1>代碼測試的重要性及必要性</h1>
測試常常是程序員十分厭倦的一個事情。測試能給我們帶來什么废离？了解這些是非常重要的侄泽，測試不可能保證一個程序是完全正確的，但是測試卻可以增強我們對程序完整的信心蜻韭，測試可以讓我們相信程序做了我們期望它做的事情悼尾。測試能夠使我們盡早的發(fā)現(xiàn)程序的bug和不足。
當然肖方，我們主要討論的是單元測試闺魏。單元測試是一個方法層面上的測試，也是最細粒度的測試俯画。用于測試一個類的每一個方法都已經(jīng)滿足了方法的功能要求析桥。在開發(fā)中，對于自己開發(fā)的模塊艰垂，只有在通過單元測試之后泡仗，才能提交到SVN庫或者Git 庫。
再一次強調(diào)材泄，你不是一個人沮焕，你的代碼有問題，同事pull下來的代碼也是有問題的拉宗，浪費大家的時間峦树。對于這件事情辣辫，我是深有感觸的，在去年的一次項目開發(fā)過程中魁巩，由于我沒有做好代碼審查和單元測試匆匆上傳到代碼庫急灭，導致其他開發(fā)人員也無法正常開展工作，還要幫著我去修改bug谷遂，這件事導致我有些自責葬馋，也在后續(xù)的開發(fā)工作中更認真，更專注肾扰，雖然偶爾也會犯錯畴嘶，但是在態(tài)度上不再吊兒郎當、無關(guān)痛癢集晚，代碼測試有時候也能體現(xiàn)出一個人的態(tài)度問題窗悯。
知道測試的重要性最好，只要寫就是對項目和編碼認真的體現(xiàn)偷拔，雖然一開始可能寫的不是很好很完善蒋院，邁出第一步就是正確的，隨著測試編碼的增多莲绰，測試用例也會逐漸完善欺旧，關(guān)鍵是要明確和認識到單元測試的重要性。
<h1>最終目的</h1>
前面論述了一下單元測試難以推進的原因以及單元測試的重要性蛤签，當我們開始認真的去做這件事了辞友，我們也要做好這件事，我們想要追求的是完美震肮，即使無法十全十美踏枣，也要盡自己的全力去爭取寫出漂亮的代碼，漂亮指得是易讀钙蒙、簡潔茵瀑、健壯，為了達到這個目的躬厌，我們就需要做覆蓋率高以及更完善的單元測試马昨。
測試的覆蓋率和完備性越高對于項目來說就越是一個利好的信號，即使做了單元測試扛施，但是較為懶散鸿捧，隨隨便便寫了幾個測試用例，這不能算得上單元測試疙渣，這種行為不僅是對項目不負責任匙奴，也是對自己不負責任。
不能和不為區(qū)別是很大的妄荔，不能代表的就是你沒有能力去做到一件事泼菌，而不為則是明明能做到卻不做谍肤。對于不能，那么首先要做的哗伯，就是通過自己的努力和學習將不能變?yōu)槟芑拇В赡墁F(xiàn)在項目中并沒有做單元測試，原因是因為不會焊刹，那就要學習如何去進行單元測試系任，掌握這個技能。
<h1>結(jié)語</h1>
認真些虐块，端正自己的態(tài)度俩滥，做好自己的單元測試。
(怎么感覺說出這些話的我這么正氣凜然贺奠，我不像是個剛正不阿的五道杠青年啊举农，哈哈哈哈哈。)
