測試驅動數據庫開發 pdf epub mobi txt 電子書 下載2025

想要找書就要到 小美書屋

立刻按 ctrl+D收藏本頁

你會得到大驚喜!!

測試驅動開發(TDD)的實踐已經幫助眾多軟件開發人員提高瞭軟件開發的質量、敏捷性、生産力和速度，《測試驅動數據庫開發》將展示如何對TDD進行調整，以便在數據庫設計與開發工作中獲得同樣強大的優勢。《測試驅動數據庫開發》共4個部分，全麵介紹測試驅動數據庫開發(TDDD)技術。第1章至～第4章重點討論數據庫的類的基本概念，第5章至第9章討論如何用麵嚮對象的方式來精益地做數據庫的類的設計以及修復設計的錯誤，第10章至第13章討論使用mocking和重構來應對由傳統方法開發齣來的遺留數據庫的兩種方法，第14章和第15章討論如何使一個數據庫應用係統能夠滿足不同客戶的不同需求，以及如何將本書的技術運用到其他數據持久化方案之中。

《測試驅動數據庫開發》適閤沒有接觸過測試驅動開發且正在開發規模較大、需求多變的數據庫應用係統的開發人員和架構師閱讀，同時也適閤尚未在持久化層運用測試先行開發技術的測試驅動開發愛好者閱讀。

Max Guernsey, III

Hexagon軟件公司的管理成員，他以該公司作為一個平颱，將真正的數據庫和用戶界麵的敏捷性引入到那些已經在中間層采用瞭敏捷軟件開發方法的組織之中。他有十餘年的軟件開發經驗，其中大部分經驗是在敏捷軟件開發的環境中獲得的，這期間的幾乎一半時間，他一直就敏捷和測試驅動數據庫開發主題，寫博客、寫作和發錶演講。通過Net Objectives，他開設“數據庫敏捷培訓”這樣一門開創性的課程，該課程專注於頻繁、安全和毫無痛苦地變更數據庫設計所需的關鍵的技術技能。他的博客maxg3prog.blogspot.com。

伍斌

獨立匠藝程序員。專注於測試驅動開發、馴服爛代碼及編程操練。除翻譯本書外,還在撰寫《馴服爛代碼》和《會運行的文檔》兩本書。自從1993年大學畢業以來,先後做過程序員、測試工程師、項目經理和軟件開發谘詢師。2013年4月創辦公益編程操練社區“bjdp.org北京設計模式學習組”。個人網站wubinben.com，微信公眾號bjdp_org。

第1章　為何改變書的內容、誰是目標讀者和什麼是障礙　1
1.1　為何改變書的內容　1
1.1.1　每天敏捷都在逐步地入侵我們的領域　2
1.1.2　若沒有TDD敏捷就沒有成效　2
1.1.3　在數據庫領域運用TDD是個挑戰　3
1.2　誰是目標讀者　3
1.2.1　TDD和OOP　3
1.2.2　應用程序和數據庫　4
1.3　什麼是障礙　4
1.3.1　數據庫就是對象　4
1.3.2　TDD適用於類，不適用於對象　4
1.3.3　我們需要數據庫的類　5
1.4　小結　6
第2章　建立數據庫的類　7
2.1　TDD中類的角色　7
2.1.1　可靠的實例化過程　7
2.1.2　測試檢查對象　8
2.2　麵嚮對象編程語言中的類　8
2.2.1　類的構建很容易：構建新對象即可　8
2.2.2　一條途徑：必要時析構　9
2.3　數據庫的類　9
2.3.1　兩條途徑：創建或改變　10
2.3.2　難點：統一兩條途徑　10
2.3.3　真實的數據庫的生長情況　11
2.3.4　將每個數據庫構建成生産數據庫會怎麼樣　11
2.3.5　所有數據庫都遵循完全相同的途徑　12
2.4　增量構建　12
2.4.1　用文檔記錄每一次數據庫的變更　12
2.4.2　標識當前版本　13
2.4.3　根據需要依次實施變更　13
2.5　實現　13
2.5.1　需求　13
2.5.2　數據庫實例化機製的僞代碼　14
2.5.3　輸入的僞代碼　14
2.6　小結　14
第3章　講一點TDD　16
3.1　測試先行的技術　16
3.1.1　編寫測試代碼　17
3.1.2　讓測試失敗得有一些有價值的啓示　19
3.1.3　看到測試運行通過　19
3.1.4　重復　20
3.2　測試即規格　21
3.2.1　“測試不是測試，而是規格”　21
3.2.2　“測試不是規格，而是測試”　22
3.2.3　測試是可運行的規格　22
3.2.4　增量設計　24
3.3　構建良好的規格　24
3.3.1　規定行為，而不是結構　24
3.3.2　從一無所有開始驅動設計，而不是從其他方式開始　25
3.3.3　從內嚮外地定義設計　25
3.3.4　從外嚮內地定義設計　27
3.4　小結　29
第4章　安全地改變設計　31
4.1　什麼是安全　31
4.1.1　違約有點糟　32
4.1.2　丟失數據可能會讓你被炒魷魚　33
4.1.3　不改設計也同樣危險　34
4.2　解決方案：過渡測試　37
4.2.1　測試驅動的實例化　37
4.2.2　建立過渡測試　38
4.2.3　纍加變化的過渡測試　40
4.2.4　過渡測試的變形　44
4.2.5　為什麼不使用公共接口　49
4.3　過渡保障　49
4.3.1　Read/Read過渡測試　49
4.3.2　每次升級時通過數據庫的類來運行　52
4.3.3　備份和失敗時迴滾　53
4.3.4　讓過渡測試充分利用過渡保障　53
4.4　小結　54
第5章　遵循接口　55
5.1　接口的優勢　55
5.1.1　更強的耦閤語言　56
5.1.2　弱耦閤的語言　57
5.1.3　共識　57
5.1.4　耦閤到數據庫的類　58
5.1.5　問題是發生瞭重復　58
5.2　像客戶對象般的遵循　58
5.2.1　創建DatabaseDesign類的需求　58
5.2.2　規定DatabaseDesign類　60
5.2.3　擺脫使用多個客戶端平颱時齣現的重復　61
5.2.4　當耦閤齣問題時會發生什麼　62
5.2.5　消除數據庫構建和客戶端代碼之間的重復　62
5.2.6　解除實現與設計之間的耦閤　63
5.3　癥結：變更　64
5.3.1　隨時間而變化的設計　64
5.3.2　記錄所有版本的設計　65
5.3.3　耦閤到設計的正確版本　68
5.4　癥結：耦閤　69
5.4.1　不同的客戶端耦閤到不同的版本　69
5.4.2　總是不得不修改所有東西也是重復　69
5.4.3　透鏡概念介紹　73
5.4.4　虛擬透鏡　76
5.4.5　“當前”透鏡　78
5.4.6　“新”透鏡　79
5.5　小結　81
第6章　定義行為　82
6.1　一組新問題　83
6.1.1　無封裝　83
6.1.2　隱藏一切　84
6.1.3　數據庫中的業務邏輯　84
6.2　知識、信息與行為　85
6.2.1　通告　86
6.2.2　知識　88
6.2.3　行為　90
6.3　由外而內地開發　92
6.3.1　定義測試　93
6.3.2　生長齣接口　94
6.3.3　生長齣行為和結構　95
6.4　用規格來實現閤理的設計　97
6.4.1　開發當下的需求，而不是將來的需求　97
6.4.2　用增量的方式構建　98
6.4.3　將訪問限定在規定的內容上　98
6.4.4　小結　99
第7章　為可維護性而構建　100
7.1　再也不要擔心未來　100
7.1.1　在當下尋找機會　101
7.1.2　針對通告進行設計　102
7.1.3　使用行為來翻譯通告和知識　106
7.2　用激情和熱忱來保護知識　108
7.2.1　不做改變是最危險的選擇　108
7.2.2　讓設計保持自然　110
7.3　當事情在未來發生時再處理　111
7.3.1　定義新的設計　111
7.3.2　引入最小的變化　113
7.3.3　讓測試運行通過　115
7.3.4　停下來，思考，重構　117
7.3.5　小結　119
第8章　錯誤與修復　121
8.1　各種錯誤　121
8.1.1　軸：好的錯誤還是壞的錯誤　122
8.1.2　軸：錯誤發布瞭沒有　124
8.2　處理好的錯誤　125
8.2.1　修復它就好瞭　125
8.2.2　現在就記錄行為　126
8.2.3　迴溯功能的根源　128
8.3　處理壞的錯誤　129
8.3.1　未發布的錯誤　129
8.3.2　已發布的錯誤　133
8.3.3　災難性的錯誤　139
8.4　小結　140
第9章　設計　141
9.1　結構與設計　142
9.1.1　結構：執行細節　142
9.1.2　測試和類信息　144
9.2　什麼是設計　144
9.2.1　概念之桶　145
9.2.2　真正的TDD中強製性的部分　147
9.3　組閤與聚閤　148
9.3.1　組閤：一件事有多個組成部分　148
9.3.2　聚閤：連接截然不同的東西　151
9.4　復用　154
9.4.1　避免將同樣的內容開發兩遍　154
9.4.2　通過組閤或聚閤來實現復用　156
9.5　抽象　157
9.5.1　發現運用抽象的機會　157
9.5.2　封裝行為　159
9.5.3　尋找各種方式來允許變化發生在依賴關係中　164
9.5.4　處理時間問題　165
9.6　小結　169
第10章　mocking　171
10.1　測試單個的行為　171
10.1.1　為什麼封裝　172
10.1.2　測試就是對那些在其控製之外的一切進行測試　172
10.1.3　從測試那裏來控製不相關的行為　173
10.1.4　mocking控製瞭行為　174
10.2　在麵嚮對象編程中的mocking　174
10.2.1　設置　175
10.2.2　解耦　179
10.2.3　隔離　181
10.2.4　集成　182
10.3　在數據庫設計中使用mocking　182
10.3.1　示例問題　183
10.3.2　示例解決方案　184
10.3.3　組閤　187
10.3.4　聚閤　188
10.3.5　為可測試性而設計　188
10.4　小結　189
第11章　重構　190
11.1　什麼是重構　190
11.1.1　改變設計但不改變行為　191
11.1.2　在測試運行通過的背景下　192
11.2　較低和較高風險的設計變更　199
11.2.1　較低風險：改變類一級的設計　199
11.2.2　中等風險：重新安排行為的邏輯　200
11.2.3　較高風險：改變知識的容器　202
11.2.4　這不是一個跳過測試的邀請　202
11.3　小結　202
第12章　遺留數據庫　203
12.1　提升到一個類　203
12.1.1　推導初始版本　204
12.1.2　用測試來釘牢過渡行為　206
12.2　控製耦閤　207
12.2.1　識彆和鎖定現有的使用數據庫的情況　207
12.2.2　按需封裝　209
12.3　控製變更　210
12.3.1　用測試驅動新的行為　210
12.3.2　按需釘牢構造行為　212
12.3.3　按需釘牢行為　213
12.3.4　實現新的行為　214
12.4　查找接縫和組件　215
12.4.1　查找接縫　215
12.4.2　封裝組件　218
12.5　小結　222
第13章　Fa?ade模式　224
13.1　使用Fa?ade的封裝　224
13.1.1　Fa?ade模式的說明　225
13.1.2　測試驅動開發齣來的新的Fa?ade數據庫　229
13.1.3　使用組閤方法的替代方案　235
13.1.4　封裝還是不封裝　235
13.2　扼殺舊接口　236
13.2.1　將正在改變的行為轉移到Fa?ade　236
13.2.2　當不再需要時刪除訪問權限和功能　237
13.3　在Fa?ade數據庫中對行為進行測試驅動開發　238
13.3.1　暴露遺留的行為　238
13.3.2　做事情的另一種方法　239
13.3.3　新的行為　239
13.4　小結　241
第14章　變奏麯　242
14.1　重要的是擁有一個類，而不是實現　243
14.2　場景：跳過那些步驟　243
14.2.1　問題　243
14.2.2　解決方案　244
14.2.3　正確的工作量　246
14.3　偏離　246
14.3.1　問題　246
14.3.2　解決方案　247
14.3.3　應用解決方案　248
14.4　通用的解決方案　252
14.5　小結　252
第15章　其他應用　254
15.1　XML　255
15.1.1　封裝　255
15.1.2　XSD Schema　255
15.1.3　XSLT過渡　257
15.1.4　對XSLT的變更進行過渡測試　258
15.2　文件係統和其他的對象目錄　259
15.2.1　對文件係統的操作進行過渡測試　259
15.2.2　Shell腳本過渡　261
15.3　數據對象　262
15.3.1　類的定義就是Schema　262
15.3.2　對Ugrader類進行過渡測試　263
15.3.3　編寫過渡　266
15.4　小結與寄語　270
· · · · · · (收起)