論單元測試之重要性

單元測試的重要性不言而喻，自我開發生涯以來，從很少注釋過過場場，到非常重視。

單元測試為什麼會讓人忽視呢？

通常情況像一些查詢或者增删改之類，拿我來說，即便報錯我大概一掃，我就知道錯誤是什麼了，該如何排查，因為就拿SpringMVC來說或者MyBatis等，再不濟就是Spring的依賴注入問題，拿MyBatis來說，要麼就是sql問題，要麼就是參數問題，再不濟就是與Spring動态掃描有關或者是mybatis中專門寫sql的配置檔案某個地方文法錯誤等，這些錯誤都是可預見的，說句不好聽的話，再不濟百度一搜，頓時分分秒就KO了。但是大家有沒有想過這樣一個問題？為什麼我們老是在犯這些重複性錯誤呢？原因是什麼呢？

不重視測試。

當然了就專業來說，我們是軟體開發工程師，專注于開發，至于測試方面，我們又不是專門的測試，管我們什麼事。

我隻能說：此言差異。

為什麼呢？

坦白的說，程式的Bug基本都是由于我們這些開發人員導緻的，比如說代碼風格亂七八糟，寫完代碼看到功能實作了，就什麼都不管了，也不多測測，以至于每次都是測試人員來測，發現誰的錯誤就通知誰，而誰誰就開始改了。

我認真想了下，其實很多錯誤是可以避免的。

就拿我公司來說，我們沒有測試沒有前端沒有運維，而我作為Java背景開發，同時兼任前端、測試、運維，記得在第一個項目初期時，為了加快項目進度，盡快讓老闆看到對應的效果，我們快速開發，能粘貼複制盡量不手寫，遇到問題百度搜尋，找到對應的解決方案，代碼複制過來，看能不能跑起來，能跑起來，就不管了，功能實作就好，跑不起來，繼續百度或者Google，當然一般情況百度比較多。

前期項目急，甚至表單校驗懶得寫，甚至有些代碼注釋都不寫，命名的話想到規範就規範，想不起，湊合吧，對于那時的我來說，這些都不是最重要的，最重要的是，每周完成工作任務，送出代碼，功能實作。當然欲速則不達，再怎麼快，總會因為這樣的錯，那樣的錯導緻項目進度延遲。而且這些錯誤是可以完全避免的。

比如我們使用的架構是Spring+MyBatis+SpringMVC,采用的表現層技術是JSP，資料庫為MySQL。

JSP對于廣大的Java同行們，并不陌生。

話走的有點偏。本篇着重與凸顯單元測試之重要性。

進入正題:

無論是前後端分離開發，還是想我上述列出的前後端不是特别分離的jsp技術等，單元測試起到不可估量的作用。

我總結到，為什麼表現層方面就會出現這樣的那樣的錯誤，關鍵在于控制層代碼有問題，也就是Controller層。

通常情況下，像我現在開發，通常Controller代碼，我會通過單元測試測試好幾遍，當然也做條件，這樣的話，可以避免一些簡單的錯誤，什麼空指針，參數問題等等。而且對于表單送出方面的，例如注冊、添加使用者、批量增加或者修改等，都是可以通過單元測試測試是否正常。

記得某位朋友曾經說過，從單元測試到業務測試再到UI測試（WEB測試），越底層，花費的時間成本越小，很容易找到錯誤，越到高層越不易排錯，當然了，排錯的方式也很重要。

這裡我想說的是，盡量能在單元測試可以預見錯誤的前提下，盡量排錯錯誤的可能性，因為到WEB階段是非常讓人痛苦的。

越簡單的事情往往都會讓人忽略的，坦白的說吧，我發現一個很貼近現實的情況，就是我們開發人員，就我個人而言，有的時候覺得存在Bug，除非其他同僚發現了，說了下，或者實際業務出問題，不然我不會改的，也懶得改。我想這是我半年前的心理。現在的我以寫的代碼讓人盡可能容易讓同僚看的懂，盡量簡潔，同時現在我對于我寫的代碼，我可以清楚的知道它是如何跑起來的，會出現哪些問題。當然了，對于一些簡單的低級錯誤，我現在已經通過單元測試排除掉了。而且再加上嚴格的表單校驗。統一規範的js書寫和每天十到十五分鐘早會的彙報和簡單交流及其加強溝通的情況下，我們的Bug越來越少了，代碼整體的性能也越來越好，簡潔優美，當然了，這還遠遠不夠，相對于第一個項目而言，我們的第二個項目一直到現在的第三個項目，越來越好了。希望繼續努力保持下去。

另外補充到:

對于前後端互動，無論是AJAX或者vue.js等等，SpringMVC的Controller代碼，基本上都是可以通過單元測試得到結果的，單元測試過了，自然出錯率會減少很多。

當然了，我說的單元測試，不是簡單的運作就可以了，而是有條件的列出實際情況，這需要根據實際業務情況而定，當然了也不能總是在單元測試了，畢竟開發進度要保持增長。

總結:

上面的描述，也許不好了解，也許重點不突出。下面我要列出我認為重要的幾點？

(1)小公司而言，背景兼任前背景開發，確定背景參數，可以在前台校驗的，盡量放在前台，這對于減輕伺服器負載非常有幫助;

(2)controller代碼中的各個@RequestMapping下的代碼是可以通過單元測試避免很多錯誤的，例如空指針或者sql有誤或者傳參類型問題或者resultType或resultMap常見的問題等，這些是可以避免的;

(3)寫代碼，無論是js或者Java代碼，一定要清楚的知道它是如何運作的，這裡說的，并不是要你知道非常清晰的每一步,因為那是計算機底層原理，這個底層原理我也不懂，正在學習中。我所說的知道它是如何運作的，是指，你能通過大腦想象，描述它是怎麼走了，比如這個參數傳到這個，但是參數值有誤，會出現什麼情況等等這樣的情況，這樣可以確定你的思維是清楚，思維的清楚，也代表代碼邏輯的清楚。作為開發人員，連自己的代碼都不知道怎麼描述，說個是以然來，那麼他的代碼是非常糟糕的;

(4)代碼，以追求簡單易懂，清楚明了為主，讓維護的人易維護，讓幾個月後的自己感謝自己。更讓整體系統性能更好。其實，很多簡單的事情堆積起來就是一件不平凡的事情。

以上就說這麼多了，歡迎程式設計的友友們不吝賜教。