日常啰嗦

看到標(biāo)題你可能會問為什么這一篇會談到代碼測試，不是說代碼優(yōu)化么？前兩篇主要是講了程序的輸出及Log4j的使用，Log能夠幫助我們進(jìn)行bug的定位，優(yōu)化開發(fā)流程，而代碼測試有什么用呢？其實測試是為了驗證自己所編寫的代碼，及時排除錯誤，減少bug，所以我認(rèn)為，減少錯誤也是優(yōu)化的一個方案體現(xiàn)，而且如果進(jìn)行了合理的單元測試，也可以幫助優(yōu)化開發(fā)流程，一旦出現(xiàn)問題，使得bug的定位過程更加迅速。

你愿意進(jìn)行單元測試嗎？

其實，像第一篇文章所說的，對于打印輸出信息，我們更習(xí)慣于使用System.out命令，所以很多時候，習(xí)慣決定了我們的編碼方式，那么你習(xí)慣于做單元測試嗎？

我感覺很多人可能都不是很樂忠于在開發(fā)工作做這件事，因為主觀意識中會覺得這是一件"麻煩"的事情，或者說效果不是很明顯的一件事。

針對于此，我也粗略的整理了一下根由，對各個原因，也分別談一下自己的想法，當(dāng)然，都是個人看法，大家覺得有用就看，覺得無用忽略即可。

  • 開發(fā)項目時并沒有明確的要求我去寫單元測試。

因為沒人要求，所以就不寫單元測試。我認(rèn)為作為一個技術(shù)人員，應(yīng)該關(guān)注自我增值和技術(shù)上的提升，要求應(yīng)該是自己提給自己的，并不是說項目沒有要求或者沒人督促我們就不去做一些事情了，這種裝鴕鳥式的態(tài)度和鉆空子的小聰明不值得提倡，我們不僅要對項目負(fù)責(zé)，其實更多的也是對自己負(fù)責(zé)，嚴(yán)格要求自己，多學(xué)習(xí)，才能更快的進(jìn)步，不要隨波逐流，不要進(jìn)入其他人的節(jié)奏中。

  • 業(yè)務(wù)邏輯比較簡單不值得編寫單元測試。

這又是一個理由，而這個理由的深層次的原因，應(yīng)該是來源于對自己的自信，自信是件好事，但是要掌握好其中的度。相對于機(jī)器來說，擁有主觀意識的人類更容易犯一些錯誤，錯誤可能不大，或者是一些低級錯誤，比如忘記寫一個分號、忘記判空、忘記類型轉(zhuǎn)換...這些都是小錯誤，但是不注意的話就會出現(xiàn)bug，然后再去花時間修修補(bǔ)補(bǔ)。
所謂的業(yè)務(wù)邏輯比較簡單，其實是相對的。當(dāng)你對某一塊業(yè)務(wù)邏輯很熟悉的時候，你自然會認(rèn)為它很簡單。然而，單元測試的必要性并不是僅僅在于測試代碼的功能是否正確，還在于，當(dāng)其他同事在了解你的業(yè)務(wù)的時候，能夠很快的通過單元測試來熟悉代碼的功能，甚至不用去讀代碼，就能夠知道它做了哪些事情。因此，寫單元測試不僅是解放了自己，更方便了別人。

  • 做了少量的單元測試。

這里可能有幾方面的原因：
1、為了完成編碼任務(wù)，沒有足夠的時間編寫單元測試。
2、在項目的前期還是盡量去編寫單元測試，但是越到項目的后期就越失控。
3、和上一個原因類似，對自己足夠自信，于是只挑一小部分進(jìn)行單元測試。

我們簡單的梳理一下開發(fā)過程，開發(fā)過程：需求—>編碼—>自測—>預(yù)發(fā)布—>測試—>回滾—>改bug—>發(fā)布—>發(fā)現(xiàn)bug—>改bug—>發(fā)布……我們可以觀察到，整個過程中改bug出現(xiàn)了很多次，它與編碼工作一樣，都是開發(fā)過程中不可缺少的一部分，編碼只是整個開發(fā)過程中的一部分，開發(fā)不僅僅是編碼而已。
編碼的完工≠項目的完工。
因為自測的不完備，導(dǎo)致預(yù)發(fā)布過程或者后期的冒煙測試難度加大，加長回滾和bug修復(fù)過程，這是一個自相矛盾的事情。