論單元測試之重要性

發表于:2020-11-16 09:53  作者:挑戰者V   來源:博客園

字體: | 上一篇 | 下一篇 |我要投稿 | 推薦標簽: 軟件測試技術 單元測試

  單元測試的重要性不言而喻,自我開發生涯以來,從很少注釋過過場場,到非常重視。
  單元測試為什么會讓人忽視呢?
  通常情況像一些查詢或者增刪改之類,拿我來說,即便報錯我大概一掃,我就知道錯誤是什么了,該如何排查,因為就拿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)代碼,以追求簡單易懂,清楚明了為主,讓維護的人易維護,讓幾個月后的自己感謝自己。更讓整體系統性能更好。其實,很多簡單的事情堆積起來就是一件不平凡的事情。
  以上就說這么多了,歡迎編程的友友們不吝賜教。

  本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8017),我們將立即處理

評 論

論壇新帖

頂部 底部


建議使用IE 6.0以上瀏覽器,800×600以上分辨率,法律顧問:上海瀛東律師事務所 張楠律師
版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2020, 滬ICP備05003035號
投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

滬公網安備 31010102002173號

51Testing官方微信

51Testing官方微博

掃一掃 測試知識全知道

日本av