在許多程序員眼中，單元測試彷佛是無關緊要的，以爲這應該是測試人員的工做。實際上，測試代碼和生成代碼一樣重要。咱們不但須要測試代碼，並且須要的是整潔的測試代碼。程序員
測試爲何要整潔web
咱們對待測試代碼須要像對待生產代碼同樣，寫以前須要進行嚴謹的思考、詳細的設計。這裏分享一下我本身的學習編程的一些經歷。編程
沒有單元測試微信
剛畢業的時候，個人代碼能夠說是年少輕狂，老是對本身充滿自信。根本就不寫單元測試，寫完以後自測也是隨意的點兩下就算自測經過了。代碼提交測試後，恐怖的事情就出現了，鋪天蓋地的bug向我襲來。天天工做有一半以上的時間是在和測試同事溝通，其他的時間是在改bug。原本1天的工做可能須要3天才能完成。當我意識到這樣作徹底是費力不討好的時候，我決心每次寫完代碼以後，要寫一段單元測試，保證單元測試經過後再提交。編輯器
隨意的單元測試單元測試
在開始寫單元測試以後，個人工做效率提升了不少，下班都比原來早了。感受寫單元測試是一個無比正確的決定。隨着項目的進行，中間處理過幾回緊急的bug fix，當時就沒有顧上去寫單元測試。然而，當我又一次完成一個新的feature的時候，像往常同樣開始跑單元測試，結果是：Failed！就是由於以前的改動致使的。因爲手裏還有其餘比較緊急的工做，單元測試又被放下了。就這樣，我又回到了沒有單元測試的工做狀態。學習
如今的我已經不像當初那樣盲目的自信了，沒有單元測試的代碼讓我感到恐慌。測試
決心重構單元測試flex
曾經有一段可用的單元測試放在我面前，但我沒有珍惜，直到失去才追悔莫及。此次我決心重建單元測試，不但要重建，還要寫一段好的單元測試。吸收上次的教訓，要使個人單元測試可擴展，可維護。把一些公共的方法抽取出來，將不一樣概念的測試進行拆分。作到「每一個概念一個測試」，測試中須要使用斷言判斷是否成功，而不是人爲查看日誌。每一個測試都要包含構造-操做-檢驗三個環節，這三個環節要定義清楚。url
這樣一來，我就有了一套整潔的單元測試，後來修改代碼後，單元測試能夠方便的進行擴展和複用，工做效率再次提高。
整潔測試的規則
整潔測試須要遵循F.I.R.S.T規則。什麼是F.I.R.S.T規則呢？
快速（Fast）
測試應該足夠快，若是測試一次須要等待很長時間，沒有人願意頻繁的運行測試，也就沒辦法快速發現問題。長此以往，咱們又會失去測試……
獨立（Independent）
測試之間應該相互獨立，一個測試的失敗不該該影響其餘的測試，不然就會致使每次測試出現一大堆問題，咱們每次只能解決最上級的測試暴露出來的問題，下級測試須要再次測試才行。這就會大大下降工做效率。
可重複（Repeatable）
測試應該在各類環境中能夠重複執行，不管是你的本地環境，測試環境仍是生產環境。測試都應該可以跑通。這樣才能保證線上的質量，測試也纔有意義。
自足驗證（Self-Validating）
測試應該有布爾值輸出（最好使用斷言），咱們不該該經過查看日誌來判斷測試是否經過，更不該該經過人爲比較兩個文本是否相同來判斷測試是否經過。這樣不但失去了測試的準確性，也浪費了咱們本身的時間。
及時（Timely）
測試應該及時編寫，在設計生產代碼的同時就應該將測試一併設計好，否則的話，當你寫好生產代碼，也許會由於某些代碼難以測試而放棄。
結語
總結一下今天討論的內容，咱們須要整潔的單元測試，它的地位與生產代碼同樣，須要咱們認真設計。設計測試的時候須要遵循F.I.R.S.T原則。
若是以爲文章不錯的話，就幫忙點個贊或者轉發一下吧。
本文分享自微信公衆號 - 代碼潔癖患者（Jackeyzhe2018）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。