重讀《從菜鳥到測試架構師》-- 測試還能驅動開發

上回說到，小艾明白了單元測試的重要性以後，也明白了單元測試須要測什麼， 這讓他的開發效率明顯有了提升，而bug密度有了明顯降低。可是，小艾的代碼依然保持着高耦合的風格，所以編寫單元測試的時候遇到了很多的阻礙，致使了測試覆蓋率偏低，可是他卻發現組長的測試覆蓋率竟然能逼近100%。

最讓小艾訝異的是，產品負責人帶來的用戶反饋要求將已有代碼進行較大幅度的變動，這個狀況他簡直沒辦法相信。就在這時，小艾聽到組長說不用擔憂，TDD可以應付這種狀況。TDD? 小艾對這個隱約有印象，彷佛曾經聽組長提起過，但本身對此一無所知，因而，他又來到了組長面前。

組長看到小艾對此十分感興趣，因而也細心地講了起來……

什麼是測試驅動開發，測試驅動的工做流程

測試驅動開發每次針對一個很小的功能點，一般是小到一個單獨的方法。流程：

    在實現新功能以前，先考慮代碼的使用需求（包括功能、過程、接口等），爲其編寫測試代碼。

    讓新寫的測試代碼和已有的測試代碼一塊兒運行。

    爲新功能編寫最少的實現代碼，切記，是最少的實現代碼。

    再次讓新測試代碼和已有代碼一塊兒運行，根據運行結果調整實現代碼，直到所有測試代碼經過。

    在此過程當中，積極地對代碼進行重構，優化代碼。

    重複上述操做，直到完成所有功能的開發。

概念

測試驅動開發是一種編寫軟件的模式，是一種敏捷開發實踐。其指導思想就是讓開發人員在編寫功能代碼以前，根據需求編寫測試代碼。思考如何對將要實現的功能進行驗證，並完成單元測試腳本的編寫，而後編寫足夠，僅僅是足夠的功能代碼知足這些測試用例，直至測試經過。

遞增地在迭代中增長新功能的單元測試和功能代碼編寫，直到完成所有功能的開發。

 

目的

測試驅動開發已經再也不是單純的測試行爲，而是上升到了一種設計行爲，或者說，測試驅動開發的目的不是爲了驗證代碼實現，而是爲了描述一段代碼的用途和用法的設計規格說明。且這種描述是無二義的，是可執行驗證的。

 

測試驅動開發與先開發後測試的異同

相同點：

    都對底層功能進行驗證

    都獲得了單元測試資產

    使項目容忍變化，可經過單元測試來保證引入的變化不會帶來負面影響。

 

不一樣點：

    測試覆蓋率不一樣：測試驅動開發要求考慮所有可能的測試，幾乎可達100%覆蓋率。後者則相對較低。

    代碼可測性不一樣：測試驅動開發中的代碼天生具備可測性，後者則不能保證。

    對需求的明晰程度不一樣：測試驅動開發編寫測試代碼的過程就是從代碼級別對需求逐漸明晰的過程。

 

測試驅動開發好處多

從上述的異同點中就能夠看到，測試驅動開發所倡導的可測試的代碼、單元測試覆蓋、重構和更優化的設計之間，是互爲因果、良性循環的行爲。測試優先使得代碼天生具備可測性，所以保證了近乎100%的測試覆蓋率，於是bug密度較低，有利於更早發現bug。

而最大的好處在於它對代碼的重構，重構能夠消除重複設計，優化設計結構，使接口更簡單，產生高內聚，低耦合的代碼，代碼複雜度的下降，也讓其更便於維護。這也意味着可以最終從設計層面對代碼作出改進。

測試驅動開發是敏捷開發的基礎，而測試優先的方式，也可以讓代碼更好地適應多變的需求。

 

聽完組長一席話，小艾明白了測試驅動開發的好處，可是很好奇，既然這麼好用爲何好像沒有被普遍使用呢？由於測試驅動開發相對傳統開發來講，是一種觀念的改變，須要時間讓你們慢慢來接受。

尾聲

小艾迴想起在開發組的這段時間，從第一次作不正規的單元測試，到後面的測試驅動開發，既增加了本身的見識，又長了本身的本事。

第四章的內容到這裏也要告一段落了，小艾協助開發人員的日子也走到了末期，應該回到本身的測試崗位去了，對代碼有必定了解的小艾，相信在接下來的測試工做中，會更加駕輕就熟~

 

想要第一時間看到這一系列文章的更新及更多精彩內容能夠掃描下面二維碼關注微信公衆號: 倚樓聽風雨的如月