設計驅動測試

出版說明
譯者序
序
關于作者
關于技術評審人
致謝
開場白
第一部分DDTvs.TDD第1章 有人弄反了
DDT要解決的問題
很難知道什么時候完成
將測試放在后期代價更大
測試設計糟糕的代碼很困難
用戶級測試很容易被遺忘
開發(fā)人員變得自負
測試有時缺少目標
對DDT的與工具無關的快速概覽
DDT的結構
DDT實戰(zhàn)
TDD與DDT的不同之處
示例項目：Mapplet2.0介紹
小結
第2章 使用TDD的HelloWorld
TDD的十大特性
10．測試驅動設計
9．完全沒有文檔
8．所有東西都是單元測試
7．TDD測試不是完全的單元測試
6．驗收測試提供針對需求的反饋
5．TDD導致盲目自信的變更
4．設計在不斷增長
3．有一些預先設計就可以了
2．TDD產(chǎn)生了大量測試
1．TDD實在太難了
使用TDD實現(xiàn)登錄用例
理解需求
考慮設計
編寫第一個測試先行的測試
編寫登錄檢查代碼從而使測試通過
創(chuàng)建模擬對象
從重構代碼看設計的浮現(xiàn)
TDD中的驗收測試
結論：TDD實在太難了
小結
第3章 使用DDT的HelloWorld
ICONIX/DDT的十大特性
10．DDT包含業(yè)務需求測試
9．DDT包含場景測試
8．測試是被設計驅動的
7．DDT包含控制器測試
6．DDT測試更靈活，更簡單
5．DDT中的單元測試是“經(jīng)典”的單元測試
4．DDT中的測試用例可以轉換成測試代碼
3．DDT測試用例指導測試計劃
2．DDT測試對開發(fā)和測試團隊都很有用
1．DDT可以消除重復工作
使用DDT實現(xiàn)登錄
步驟1：創(chuàng)建健壯性圖
步驟2：創(chuàng)建控制器測試
步驟3：添加場景
步驟4：將控制器測試用例轉換成為類
步驟5：生成控制器測試代碼
步驟6：繪制序列圖
步驟7：創(chuàng)建單元測試用例
步驟8：填充測試代碼
小結
第二部分真實世界中的DDT：Mapplet2.0旅游網(wǎng)站
第4章 Mapplet項目簡介
ICONIX流程/DDT十大“To-Do”列表
10．創(chuàng)建架構
9．對需求達成共識并進行測試
8．從問題域驅動設計
7．使用UI故事板編寫用例
6．編寫場景測試驗證用例
5．測試概要設計和詳細設計
4．經(jīng)常更新模型
3．保持測試腳本與需求同步
2．更新自動化測試
1．比較待發(fā)布版本和原始用例
小結
第5章 詳細設計和單元測試
單元測試十大“To-Do”列表
10．從序列圖開始
9．在設計中標識測試用例
8．為每個測試用例編寫場景
7．聰明測試：避免重疊測試
6．把測試用例轉換為UML類
5．編寫單元測試和相關的代碼
4．編寫白盒單元測試
3．使用模擬對象框架
2．用單元測試測試算法邏輯
1．編寫集成測試的獨立套件
小結
第6章 概要設計和控制器測試
控制器測試十大“To-Do”列表
10．從健壯性圖開始
9．為控制器標識測試用例
8．為每個測試用例定義一個或者多個場景
7．填寫描述、輸入和驗收標準
6．生成測試類
5．實現(xiàn)測試代碼
4．編寫容易測試的代碼
3．編寫“灰盒”控制器測試
2．串聯(lián)控制器測試
1．編寫集成測試的獨立套件
小結
第7章 驗收測試：擴展用例場景
場景測試的十大“To-Do”列表
Mapplet用例
10．從一個敘述性用例開始
9．把這個用例轉換成一個結構化的場景
8．確保涵蓋所有的可選方案和意外場景
7．增加前置條件和后置條件，將每個場景分支連接起來
6．生成活動圖來檢查結構化場景
5．創(chuàng)建外部測試集來細化場景
4．把測試用例放進用例圖
3．進入EA測試視圖
2．根據(jù)需要細化場景
1．為測試團隊生成測試計劃文檔
這個過程的精髓是……
小結
第8章 驗收測試：業(yè)務需求
十大需求測試“To-Do”列表
10．從一個域模型開始
9．編寫業(yè)務需求測試
8．對需求進行建模和整理
7．從需求創(chuàng)建測試用例
6．與用戶一起審查你的計劃
5．編寫手工測試腳本
4．編寫自動化需求測試
3．導出需求測試用例
2．使測試用例可見
1．讓你的團隊參與其中！
小結
第三部分高級DDT
第9章 單元測試的反模式（反面案例）
末日圣殿（特指某一種代碼）
大背景
HotelPriceCalculator類
支持類
服務類
反模式
10．復雜的構造函數(shù)
9．濫用類繼承
8．靜態(tài)微觸發(fā)器
7．靜態(tài)方法和變量
6．單例設計模式
5．緊耦合
4．UI代碼里實現(xiàn)業(yè)務邏輯
3．濫用私有屬性
2．聲明為final的服務對象
1．熱心的程序員開發(fā)的不成熟的功能
小結
第10章 為易于測試而設計
十大為測試而設計的“To-Do”列表
末日圣殿——徹底修正
用例——確定我們需要做什么
識別控制器測試
計算總價格測試
獲取最新價格測試
為易于測試而設計
10．將初始化代碼放在構造函數(shù)之外
9．慎用繼承
8．避免使用靜態(tài)初始化塊
7．使用對象級別的方法和變量
6．避免使用單例設計模式
5．保持類解耦合
4．將業(yè)務邏輯放在UI代碼之外
3．使用“黑盒”和“灰盒”測試
2．為常量預留“final”修飾符——通常需要避免修飾復雜類型（如ServiceObjects）為final
1．堅持使用用戶用例和設計
QuoteHotelPrice用例的詳細設計
控制器測試：計算總價
控制器測試：獲得最新價格的測試
重構設計和代碼
小結
第11章 自動化的集成測試
十大集成測試“To-Do”列表
10．在概要設計里尋找測試模式
9．不要忘記安全性測試
安全性測試：SQL注入攻擊
安全性測試：建立安全會話
8．決定編寫哪個“等級”的集成測試
三個等級的不同點
了解編寫哪個等級的集成測試
7．概要設計驅動單元/控制器級別的集成測試
6．從用例場景驅動場景測試
5．編寫端到端場景測試
模擬一個場景中的步驟
共享測試數(shù)據(jù)庫
Mapplet例子：“高級搜索”用例
VanillaxUnit場景測試
4．使用“業(yè)務友好”型測試框架
3．將測試GUI代碼作為場景測試的一部分
2．不要低估集成測試的難度
網(wǎng)絡延遲
數(shù)據(jù)庫元數(shù)據(jù)變化
隨機變化的（又名“敏捷”）接口
遠程系統(tǒng)中的bugs
陰雨天
1．不要低估集成測試的價值
編寫集成測試的關鍵點
小結
第12章 單元測試算法
十大算法測試“To-Do”列表
10．從概要設計的控制器開始工作
9．將控制器擴展成算法設計
8．把圖和域模型對應起來
7．分割那些看上去不止做一個檢查的判斷結點
6．為每個結點（活動和判斷結點）建立一個測試用例
5．為每個測試用例定義測試場景，一組輸入和期望結果
4．按照算法，從不同的源中創(chuàng)建輸入數(shù)據(jù)
3．把邏輯流程對應到獨立的方法和類上
2．編寫“白盒”單元測試
1．在其他類型的設計圖上使用DDT技術
小結
附錄愛麗絲漫游用例國
介紹
第1部分
愛麗絲在看書的時候睡著了
用例驅動開發(fā)的承諾
一種把用例文本和對象連接起來的分析模型
簡潔且直接
>還是>
我們遲到了!我們必須開始編碼了！
愛麗絲想知道如何才能把用例變成代碼
抽象的……基本的
有點太過抽象了?
目的中心化……
我們真的打算為每個用例都指定這些東西嗎？
第2部分
愛麗絲口渴了
愛麗絲感到頭暈
設想……（敬請約翰·列儂原諒，這首歌改編自他的作品）
結對編程意味著再也不用把需求寫下來了
沒時間去寫需求了
你也許也會說“代碼就是設計”
誰在乎用例？
C3項目被中止了
一次且只有一次？
沒有寫下需求之前，愛麗絲拒絕開始寫代碼
你因為預先設計而被定罪……
CMM已經(jīng)死了，砍掉她的腦袋！
一些嚴肅的設計重構
第3部分
愛麗絲醒了
縮小“什么”和“如何”之間的距離
靜態(tài)模型和動態(tài)模型被連接在了一起
行為被定位到序列圖里
這里面的教訓在于……
尾聲——亂七八糟的測試……
索引