1. 程式人生 > >論單元測試之重要性

論單元測試之重要性

表單 曾經 mybatis 服務 request 第一個 完成 分離 能說

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

單元測試為什麽會讓人忽視呢?

通常情況像一些查詢或者增刪改之類,拿我來說,即便報錯我大概一掃,我就知道錯誤是什麽了,該如何排查,因為就拿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)代碼,以追求簡單易懂,清楚明了為主,讓維護的人易維護,讓幾個月後的自己感謝自己。更讓整體系統性能更好。其實,很多簡單的事情堆積起來就是一件不平凡的事情。

以上就說這麽多了,歡迎編程的友友們不吝賜教。

論單元測試之重要性