Junit單元測試驅動開發(fā)_第1頁
Junit單元測試驅動開發(fā)_第2頁
Junit單元測試驅動開發(fā)_第3頁
Junit單元測試驅動開發(fā)_第4頁
Junit單元測試驅動開發(fā)_第5頁
已閱讀5頁,還剩30頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、測試驅動開發(fā)2目錄目錄測試驅動開發(fā)簡介測試驅動開發(fā)入門測試與重構3測試驅動開發(fā)簡介測試驅動開發(fā)簡介Why 為什么會出現(xiàn)測試驅動開發(fā)What 什么是測試驅動How 測試驅動所要達到的目標4為什么會出現(xiàn)測試驅動開發(fā)這段代碼究竟想表達什么意思?奇怪了,怎么代碼跟開發(fā)文檔上有這么大的差別???代碼現(xiàn)在越來越亂了,我都不敢修改代碼了,修改了這個地方,天曉得會引起多少別的地方出錯啊!這個地方的代碼怎么好象在那個地方看到過啊?這個程序里怎么會有這么多的重復代碼呢?開發(fā)人員開發(fā)人員5他們到底在搞什么啊,有沒有從用戶的角度考慮啊,我新增一個票據(jù)訂單,訂單項竟然可以輸入負數(shù)。!。為什么會出現(xiàn)測試驅動開發(fā)測試人員測試

2、人員這下好了,讓他們修改了一個BUG,現(xiàn)在一下子來了這么多的BUG項目部在干什么啊,BUG怎么這么多,他們有沒有自己先測試一下啊6什么是測試驅動QA 項目部在干什么啊,BUG怎么這么多,他們有沒有自己先測試一下啊 這下好了,讓他們修改了一個BUG,現(xiàn)在一下子來了這么多的BUG 他們到底在搞什么啊,有沒有從用戶的角度考慮啊,我新增一個票據(jù)訂單,訂單項竟然可以輸入負數(shù)。7測試驅動想達到的目標測試驅動想達到的目標測試驅動是一種開發(fā)形式 首先要編寫測試代碼 除非存在相關測試,否則不編寫任何產(chǎn)品代碼 由測試來決定需要編寫什么樣的代碼 要求維護一套詳盡的測試集clean code that work目錄目

3、錄測試失敗時,才寫代碼消除重復設計,優(yōu)化設計結構代碼整潔可用9測試驅動開發(fā)入門測試驅動開發(fā)入門測試驅動開發(fā)簡介測試驅動開發(fā)入門測試與重構如何開始如何開始如何開始原則測試技術原則一原則一: :測試隔離測試隔離不同代碼的測試應該相互隔離。對一塊代碼的測試只考慮此代碼的測試,不要考慮其實現(xiàn)細節(jié)12原則二:一頂帽子原則二:一頂帽子做不同的事,承擔不同的角色。注意力集中在當前工作上,不要過多考慮其他方面的細節(jié),保證頭上只有一頂帽子13原則三:測試列表原則三:測試列表需要測試的功能點很多在任何階段想添加功能需求問題時,把相關功能點加到測試列表中,再繼續(xù)手頭工作14原則四:先寫斷言原則四:先寫斷言編寫對功能

4、代碼的判斷用的斷言語句,然后編寫相應的輔助語句15原則五:可測試性原則五:可測試性遵循比較好的設計原則的代碼都具備較好的測試性。比如比較高的內(nèi)聚性,盡量依賴于接口等16原則六:及時重構原則六:及時重構無論是功能代碼還是測試代碼,對結構不合理,重復的代碼等情況,在測試通過后,及時進行重構17原則七:小步前進原則七:小步前進把所有的規(guī)模大、復雜性高的工作,分解成小的任務來完成每個功能的完成就走測試代碼功能代碼測試重構的循環(huán)18范圍、粒度范圍、粒度對哪些功能進行測試?會不會太繁瑣?什么時候可以停止測試?對那些你認為應該測試的代碼進行測試大師Kent Benk 什么時候寫什么時候寫明確當前要完成的功能

5、??梢杂涗洺梢粋€ TODO 列表快速完成針對此功能的測試用例編寫測試代碼編譯不通過編寫對應的功能代碼測試通過對代碼進行重構,并保證測試通過如何編寫用例如何編寫用例l 操作過程盡量模擬正常使用的過程l 全面的測試用例應該盡量做到分支覆蓋,核心代碼盡量做到路徑覆蓋l 測試數(shù)據(jù)盡量包括:真實數(shù)據(jù)、邊界數(shù)據(jù)l 測試語句和測試數(shù)據(jù)應該盡量簡單,容易理解l 為了避免對其他代碼過多的依賴,可以實現(xiàn)簡單的樁函數(shù)或樁類(Mock Object)l 如果內(nèi)部狀態(tài)非常復雜或者應該判斷流程而不是狀態(tài),可以通過記錄日志字符串的方式進行驗證如何編寫用例如何編寫用例在開發(fā)一個新的功能之前:OK,我們知道這個method中的

6、這段代碼要做什么,而且這段代碼也足夠簡單。測試隔離不同代碼的測試應該相互隔離。對一塊代碼的測試只考慮此代碼的測試,不要考慮其實現(xiàn)細節(jié)一頂帽子做不同的事,承擔不同的角色。注意力集中在當前對應工作上,而不要過多的考慮其他方面的細節(jié),保證頭上只有一頂帽子測試列表需要測試的功能點很多在任何階段想添加功能需求問題時,把相關功能點加到測試列表中,然后繼續(xù)手頭工作先寫斷言編寫對功能代碼的判斷用的斷言語句,然后編寫相應的輔助語句可測試性遵循比較好的設計原則的代碼都具備較好的測試性。比如比較高的內(nèi)聚性,盡量依賴于接口等及時重構無論是功能代碼還是測試代碼,對結構不合理,重復的代碼等情況,在測試通過后,及時進行重構

7、小步前進把所有的規(guī)模大、復雜性高的工作,分解成小的任務來完成每個功能的完成就走測試代碼功能代碼測試重構的循環(huán)如何編寫用例如何編寫用例對哪些功能進行測試?會不會太繁瑣?什么時候可以停止測試?如何編寫用例如何編寫用例如果你要寫一個新的功能,請先寫她的測試例子如果你要在沒有經(jīng)過測試的代碼上寫新的功能,請先寫目前代碼的測試例子如果你要Fix一個Bug,請先為這個Bug寫一個測試例子如果你要重構沒有測試過的代碼,請先寫一個測試例子如果你發(fā)現(xiàn)一個邊緣例外值,請為她寫一個測試例子如何編寫用例如何編寫用例操作過程盡量模擬正常使用的過程全面的測試用例應該盡量做到分支覆蓋,核心代碼盡量做到路徑覆蓋測試數(shù)據(jù)盡量包括

8、:真實數(shù)據(jù)、邊界數(shù)據(jù)測試語句和測試數(shù)據(jù)應該盡量簡單,容易理解為了避免對其他代碼過多的依賴,可以實現(xiàn)簡單的樁函數(shù)或樁類(Mock Object)如果內(nèi)部狀態(tài)非常復雜或者應該判斷流程而不是狀態(tài),可以通過記錄日志字符串的方式進行驗證JUnitJUnit介紹介紹首先確定你要做什么(不是要如何做?。?比如說一個論壇的增加用戶的功能,我們需要又一個method來增加一個用戶: public void addAccount( Account account ) 當然包括成功增加一個用戶(在數(shù)據(jù)庫中插入一條紀錄) 還包括如果已經(jīng)由一個相同的用戶,應該返回一個用戶已存在的消息JUnitJUnit介紹介紹然后為這

9、個功能(Method)寫單元測試例子( Unit Test ) 單元測試例子要覆蓋這個Method的 “做什么”。 所以我們至少有了兩個測試例子: Test Case 1: 測試成功增加一個用戶 Test Case 2: 測試增加一個已存在的用戶 其他邊緣情況測試: Test Case 3: 傳入的Account對象為NULL目錄目錄28測試與重構測試與重構什么是重構什么是重構重構的好處重構的好處重構的時機重構的時機存在重復的時候覺察到代碼所表達的意圖不明確的時候代碼有味道的時候重構與測試的關系重構與測試的關系 大話西游之單元測試大話西游之單元測試 轉載轉載 “我知道這個項目bug很多,無法按時完成,即使老板把我炒了也是應該的。曾經(jīng)有一個做單元測試的機

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論