最近要寫幾篇和單測有關的文章,找出來本身好久寫的文章。發出來,先作個預告。歡迎交流。程序員
做爲一個開發人員。不少人不多寫單元測試,甚至不寫單元測試。markdown
總結一下開發人員不寫單測的緣由無非有如下幾種:ide
一、認爲寫單測浪費時間。 二、認爲測試不該該是開發人員來作的。 三、自信我寫的代碼沒有問題,不須要單測。 四、不知道單測的重要性。 五、不知道單測的好處。
那麼針對以上這幾種觀點,今天就逐個分析一下。到底單元測試有沒有那麼重要。函數
在業務高速發展的今天,不少時候項目來的時候要的都很急。好像要是我不把這個功能在幾天以內搞完整個公司都要倒閉了同樣。因此,不少開發人員都把主要的時間用在寫業務邏輯代碼上。不少人都是有時間的時候纔會寫一些簡單的單元測試代碼,若是項目比較忙的話就不寫單元測試。單元測試
不少程序員的項目都是這樣完成的:測試
寫代碼---->集成測試---->改bug---->集成測試---->預發佈測試---->改bug---->正式發佈---->發生故障---->改bug---->發佈---->改bug---->....google
能夠看到,改bug過程貫穿着整個軟件的生命週期。改bug不少人都知道怎麼改,就是要先定位問題,而後再解決問題。每每定位問題都是比較複雜的,通常都須要很長的時間。編碼
若是有了單元測試可能就會節省不少時間,經過單測能夠減小不少bug的發生,也能幫助咱們快速的定位問題。只要在集成測試以前作好單元測試。在經過單元測試以後,咱們就能夠認爲這部分代碼是可靠的,那麼就能夠放心的進行項目集成。debug
固然,有了單元測試,並不能保證代碼不出現bug。可是,單元測試能夠在軟件開發過程的早期就能發現問題。只要單測的測試用例足夠好,那麼就能夠避免不少低級錯誤。設計
那麼,爲何仍是不少人認爲單元測試浪費時間呢,我的分析緣由多是這樣的。開發人員認爲個人時間就應該用來寫業務邏輯代碼。項目出現了bug,我也應該用個人時間來解決這個bug。他們認爲個人時間花費在這件事上我是承認的,因此個人時間就不叫浪費。歸根結底,他們就是沒有意識到單元測試所帶來的好處。一旦他們發現,經過單元測試可讓我更早的發現問題等等好處,那麼他們也會承認把時間花費在寫單測上。
在這裏,能夠先下一個結論:好的單測不只不會浪費時間,還會大大節省咱們的時間。至於爲何會節省時間以及什麼叫好的單測會在後面介紹。
這裏暫不分析到底應不該該有單獨的測試人員,這是一個很有爭議的話題(一部分人認爲,開發就應該是全棧的。還有一部分人認爲開發就應該只關注業務寫業務代碼)。這裏只分析單元測試到底應該由誰來作。有人認爲,單元測試也是測試的一種手段,應該交給專門的QA去作。也有人認爲單元測試應該是開發人員來寫,那麼,單元測試到底應不該該開發人員寫呢?
單元測試必須由最熟悉代碼的人來寫。這是好的單元測試的標準之一。那麼還能有誰比寫代碼的人更瞭解代碼呢?代碼的做者最瞭解代碼的目的、特色和實現的侷限性。因此,寫單元測試沒有比做者更適合的人選了。單獨的測試人員進行單元測試,每每工做量大,週期長,耗費巨大,其結果事倍功半。軟件的開發者老是應當負責程序的單個單元的測試,保證每一個單元可以完成設計的功能,其實在不少狀況下,開發者也應進行集成測試。
個人觀點覺得,開發人員寫了一個函數,就要對這個函數負責,就有義務保證這個函數能夠準確的執行。單測即是一個很好的手段。因此,若是要寫單測,就應該開發人員本身來寫。
有人能寫出天衣無縫的代碼麼?答案是否認的!
我認爲程序員都是天生驕傲的。雖然程序員每每都會說:在我機器上明明是好的呀,是否是你用的方式不對呀。可是,好的程序員應該在說完這句話以後會偷偷的去排查問題。
寫代碼不是能夠一蹴而就的,必須通過各類各樣的測試,單元測試只是其中一種。
因此,不管你是一個多麼天生驕傲的程序員,你都不是神!因此,你也須要單測。
不少程序員寧願把時間花費在寫業務邏輯代碼上,他們多數是有時間的時候纔會寫一些簡單的單元測試代碼,若是項目比較忙的話就不寫單元測試。據我所知,只有少數的公司會要求項目上線必須達到必定百分比的代碼覆蓋率(軟件測試中的一種度量,描述程式中源代碼被測試的比例和程度),大多數公司都不是很重視這一項,全部,不少人就不過重視單元測試。可是,不少發生故障的經驗告訴咱們,不少問題是能夠經過單元測試避免的。
其實單元測試的重要性很簡單,就是一句話:不寫單元測試,你怎麼知道你的代碼寫的對不對?沒有足夠豐富的測試用例,你怎麼知道用戶會怎麼使用到你的代碼,你又怎麼會知道你的代碼應該怎麼被執行呢?
因此,單元測試很重要。和寫代碼同樣重要。無單測,不編碼!
前面說了這麼多,其實以上這些問題都有一個最最根源的問題,那就是不少程序員不寫單測的最最根本緣由是他們根本不知道寫單測和不寫單測的區別。不知道寫了單測能帶來好處。因此他們會認爲寫單測是浪費時間,因此他們纔會認爲單測不該該是由我來寫,因此他們纔會認爲我不須要寫單測。
那麼,單元測試到底能帶來哪些好處呢?
J.Timothy King寫過一篇關於先寫單元測試有哪些好處的文章:Twelve Benefits of Writing Unit Tests First(先寫單元測試的十二個好處),這裏挑其中幾個顯而易見和比較突出的好處介紹一下。
單元測試的目的就是經過足夠準確的測試用例保證代碼邏輯是正確。因此,在單測過程當中,必然能夠解決一些bug。由於,一旦某條測試用例沒有經過,那麼咱們就會修改被測試的代碼來保證可以經過測試。
通常解決bug的思路都是先經過各類手段定位問題,而後在解決問題。定位問題的時候若是沒有單元測試,就只能經過debug的方式一點一點的追蹤代碼。解決問題的時候更是須要想盡各類方法來重現問題,而後改代碼,改了代碼以後在集成測試。
由於單元規模較小,複雜性較低,於是發現錯誤後容易隔離和定位,有利於調試工做。
我相信,對一個程序員來講最痛苦的事就是修改別人的代碼。有時候,一個很大的系統會致使不少人不敢改,由於他不知道改了一個地方會不會致使其餘地方出錯。能夠,一旦有了單元測試,開發人員能夠很方便的重構代碼,只要在重構以後跑一遍單元測試就能夠知道是否是把代碼「改壞了」
不寫單測也許能讓開發速度更快,可是沒法保證本身寫出來的代碼真的能夠正確的執行。寫單測能夠較少不少後期解決bug的時間。也能讓咱們放心的使用本身寫出來的代碼。總體提升開發速度。
據我說知,在facebook是沒有QA的,他們的全部代碼都是經過單元測試來保證可以正確執行的。在google也很重視單測,國外這樣的大公司都會要求單測的代碼覆蓋率達到一個高的水平,不然是絕對不會容許代碼發不到線上的。
因此,經過這樣一篇文章,但願讀者能夠重視單元測試,並在實際項目中運用起來。可是,也請記得,單測只能在必定程度上減小bug的發生,並非寫了單測就不會在發生問題。
無單測,不編碼!