測試驅(qū)動的iOS開發(fā)

前言

我向其他開發(fā)者講授測試驅(qū)動開發(fā)很大程度上是出于偶然。本來安排我在會議上關(guān)于另一個話題發(fā)表演講，而我的一個朋友則講述TDD（Test Driven Development，測試驅(qū)動開發(fā)）。不過朋友的妻子選擇那周末生雙胞胎（我認(rèn)為是這樣的，我可不是這方面的專家），所以Chunk，也就是委托我寫這本書的人，問我能不能也關(guān)于TDD發(fā)表演講。由此機(jī)緣，最終使我開始了為期一年的寫書過程。通常來說，真實狀況并不像我們彼此之間講述的那樣美好。實際上，我初次接觸單元測試是在很多年前了。在成為專業(yè)的軟件開發(fā)者之前，我曾在一家制作基于GNUstep（由自由軟件基金會所制作，可運(yùn)行于Linux與其他平臺的Cocoa庫）產(chǎn)品的公司里當(dāng)測試人員。據(jù)我當(dāng)時所知，單元測試就是確保軟件產(chǎn)品的每個小部件都能正常運(yùn)行的一種開發(fā)方法。當(dāng)這些小部件合并為大的組件時，按理說它也能正常運(yùn)行才是。這種理解一直持續(xù)到了我從事第一份編程工作時，那個工作是負(fù)責(zé)某個跨平臺安全軟件的Mac系統(tǒng)版本開發(fā)。（這里我又一次省略了一件事—幾年前，我曾做過一個為期6周的LISP外包程序。每個人都曾做過一些并不為之驕傲的事情。）在做這份工作時，我參加了一個TDD培訓(xùn)課程，這項課程是由經(jīng)?；钴S于面向?qū)ο缶幊逃懻摃系腒evlin Henney所開設(shè)的。他除了寫過很多文章之外，還曾編輯過一本書，名叫《每個程序員都應(yīng)該知道的97件事》  。就是通過學(xué)習(xí)這個課程，我才最終意識到測試驅(qū)動開發(fā)的主旨是使得開發(fā)者對其編寫的代碼更有信心。隨著學(xué)習(xí)的深入，我還領(lǐng)悟到測試驅(qū)動開發(fā)可以使開發(fā)者在修改代碼時心里更加踏實。當(dāng)對TDD有足夠的了解，并能夠從實踐的教訓(xùn)中總結(jié)經(jīng)驗時，我終于將TDD當(dāng)成了日常開發(fā)的一部分，并弄懂了其中哪些方法適合我，哪些不適合。幾年之后，我能夠接受Chuck的邀請，來做一場關(guān)于TDD的演講了。真心希望這本書能夠讓讀者領(lǐng)悟到測試驅(qū)動開發(fā)的好處，并將其納入日常編碼工作中，同時也希望讀者能稍花點時間就掌握它，不要像筆者這樣花費了5年左右的時間。有很多關(guān)于單元測試的書，其中某些書的作者也曾參與測試框架的編寫與設(shè)計。這些書都很好，不過，它們都沒有特別針對Cocoa Touch的開發(fā)者。筆者的這本書提供了以O(shè)bjective-C語言所編寫的范例，講述了Xcode及相關(guān)工具的用法，并以Cocoa的編程風(fēng)格書寫代碼。但愿本書能夠?qū)y試驅(qū)動開發(fā)的原理講得更加易懂，并使它與iOS開發(fā)者的工作聯(lián)系起來。另外，還有測試工具的問題。對于寫單元測試有很多種工具可用，具體采用哪個，還要取決于眾多不同的工具與框架所提供的功能。盡管本書會提到它們之間的一些差別，但是筆者打算專注于講解Apple所提供Xcode開發(fā)環(huán)境及其所附OCUnit測試框架的用法。這么做的原因很簡單，那就是適用性：任何想嘗試單元測試或TDD的開發(fā)者，只要學(xué)習(xí)了本書所講的知識，使用標(biāo)準(zhǔn)的開發(fā)工具，并具備一定的決心，就可以立刻投入工作中。如果讀者覺得標(biāo)準(zhǔn)的測試工具缺少某些功能或者不太好用，那你當(dāng)然可以研究其他工具的用法，甚至自己寫一個測試工具—只是記得要測試它哦！在成長為一個迷戀測試的程序員的過程中，我學(xué)到了很多。其中之一就是，想要當(dāng)一個好的軟件工程師，最好的辦法就是與其他開發(fā)者交流。如果你對本書內(nèi)容或者通用的TDD開發(fā)方法有任何評論或建議，歡迎在Twitter上與我交流討論（我的用戶名是iamleeg）。致謝牛頓曾說過，“如果我比別人看得更遠(yuǎn)，那是因為我站在巨人的肩上”，當(dāng)然了，他的這個說法綜合了數(shù)個世紀(jì)以來作者們不斷拓展與完善的那個隱喻。與此相似，本書也不是憑空寫出來的，有很多要感謝的人，若全部寫出他們的名字的話，要從愛達(dá)勒芙蕾絲伯爵夫人開始，用好多頁才能寫完。如果要寫一份簡潔一些的致謝表，那么首先要感謝的就是培生（Pearson）出版集團(tuán)的諸位同仁，是他們促成了本書的出版發(fā)行。還要感謝Chunk、Trina與Olivia，是他們持續(xù)督促我完成此書的。此外還有本書的技術(shù)審校者Saul、Tim、Alan、Andrew、兩位名為Richard的先生、Simon、Patrick以及Alexander，感謝你們在排查本書草稿中錯誤的過程中所做的出色工作，如果還有錯誤的話，則應(yīng)歸咎于我。感謝Andy與Barbara，你們所做的文字潤色工作，將一些由程序員草草寫就的文字變成了優(yōu)雅的英語文句。感謝xUnit測試框架的設(shè)計者Kent Beck先生，沒有他對于測試的見解，我將無處下筆，同樣，也感謝xUnit框架的Objective-C版本制作方Sente SA公司。還必須提到的是Apple的開發(fā)工具制作團(tuán)隊，他們?yōu)榱俗屓澜绲膇OS開發(fā)者能夠使用單元測試所做的努力比其他人都要多。與別人相比，Kevlin Henney更讓我領(lǐng)略到了測試驅(qū)動開發(fā)之美，讓我避免了很多bug，謝謝你！最后，感謝Freya在沒日沒夜的寫書過程中對我的支持與理解。如果此刻你正在讀這段話，我想你可能會更加了解我的。

內(nèi)容概要

　　本書是目前僅有的一本講解如何將測試驅(qū)動的開發(fā)方法應(yīng)用到iOS開發(fā)中的權(quán)威教程，從測試工具、測試驅(qū)動開發(fā)方法和技巧、基于測試驅(qū)動開發(fā)方法的軟件設(shè)計等多角度完美地展現(xiàn)了測試驅(qū)動開發(fā)方法與iOS開發(fā)的結(jié)合，不僅能使iOS開發(fā)者迅速掌握測試驅(qū)動的開發(fā)方法，還能使他們在產(chǎn)品需求、軟件設(shè)計、測試有效性與開發(fā)效率之間達(dá)成達(dá)到很好的平衡。
　　全書一共13章：第1章簡單介紹了通用的軟件測試知識，以及軟件測試的目標(biāo)；第2章介紹如何利用測試驅(qū)動開發(fā)與單元測試來達(dá)到這個目標(biāo)；第3章將如何進(jìn)行單元測試的設(shè)計與編寫；第4章將深入學(xué)習(xí)如何使用Apple的開發(fā)工具中綁定的OCUnit測試框架；第5章揭示在iOS應(yīng)用程序的開發(fā)過程中如何從最初的需求規(guī)格書演進(jìn)到最終產(chǎn)品；第6章闡述如何實現(xiàn)從需求描述中提取出來的數(shù)據(jù)模型；第7章將實現(xiàn)應(yīng)用程序的業(yè)務(wù)邏輯；第8章以測試用例為指導(dǎo)，為BrowseOverflow應(yīng)用程序設(shè)計并實現(xiàn)網(wǎng)絡(luò)通信功能；第9章講述如何編寫視圖控制器的代碼，讓BrowseOverflow程序?qū)⑦@些信息展示給用戶；第10章將以上述類整合起來，實現(xiàn)一個功能完備且能夠正常運(yùn)行的應(yīng)用程序；第11章講解一些用于移除類之間的依賴性、代碼運(yùn)行環(huán)境依賴性以及線程依賴性的設(shè)計范式；第12章回答了在什么情況下適合采用TDD開發(fā)方式；第13章展望了業(yè)界一些更為新穎的功能、一些對已有技術(shù)的擴(kuò)展以及一些有用的開發(fā)工具。
　　本書適合從事iOS測試驅(qū)動的軟件開發(fā)人員和程序員閱讀。

作者簡介

　　Graham Lee，資深安全顧問與iOS/Mac開發(fā)專家，在全球iOS/Mac開發(fā)者社區(qū)中享有盛名。多次受邀在Voices
That Matter、NSConference、Association of C and C++
Users以及Qcon等國際技術(shù)會議上展示高質(zhì)量的Cocoa軟件工程實踐。在軟件測試領(lǐng)域有深厚的積累和實踐經(jīng)驗，從６年前主管一個基于GNUstep的服務(wù)器應(yīng)用程序的測試開發(fā)工作開始深入研究OCUnit與單元測試技術(shù)。在研究iOS開發(fā)前，曾為OS
X、NeXTSTEP及其他類UNIX系統(tǒng)開發(fā)過應(yīng)用程序。他還是一位經(jīng)驗豐富的技術(shù)作家，著有《Professional Cocoa
Application Security》一書。

書籍目錄

譯者序
前言
第1章　軟件測試與單元測試簡介
1.1　軟件測試的目標(biāo)
1.2　軟件測試由誰來做
1.3　何時進(jìn)行軟件測試
1.4　測試實踐舉例
1.5　單元測試的適用范圍
1.6　測試驅(qū)動開發(fā)對iOS開發(fā)者的意義
第2章　測試驅(qū)動開發(fā)技巧
2.1　測試先行
2.2　“失敗、成功、重構(gòu)”三部曲
2.3　設(shè)計易于測試的應(yīng)用程序
2.4　更多有關(guān)重構(gòu)的知識
2.5　不要實現(xiàn)目前用不到的功能
2.6　在編碼前、編碼中及編碼后進(jìn)行測試
第3章　如何寫單元測試
3.1　需求
3.2　使用已知的輸入數(shù)據(jù)來運(yùn)行代碼
3.3　查看運(yùn)行結(jié)果是否符合預(yù)期
3.4　驗證結(jié)果
3.5　使測試代碼更具可讀性
3.6　將多個測試用例組織起來
3.7　重構(gòu)
3.8　總結(jié)
第4章　測試工具
4.1　Xcode附帶的OCUnit測試框架
4.2　OCUnit的替代方案
4.2.1　GTM
4.2.2　GHUnit
4.2.3　CATCH
4.2.4　OCMock
4.3　持續(xù)集成工具
4.3.1　Hudson
4.3.2　CruiseControl
4.4　總結(jié)
第5章　針對iOS應(yīng)用程序的測試驅(qū)動開發(fā)
5.1　產(chǎn)品目標(biāo)
5.2　用例
5.3　執(zhí)行方案
5.4　開始制作程序
第6章　數(shù)據(jù)模型
6.1　Topic類
6.2　Question類
6.3　Person類
6.4　將Question類與其他類關(guān)聯(lián)起來
6.5　Answer類
第7章　應(yīng)用程序邏輯
7.1　執(zhí)行方案
7.2　建立Question對象
7.3　用JSON數(shù)據(jù)構(gòu)建Question對象
第8章　網(wǎng)絡(luò)相關(guān)代碼
8.1　NSURLConnection類的設(shè)計
8.2　實現(xiàn)StackOverflowCommunicator類
8.3　總結(jié)
第9章　視圖控制器
9.1　類結(jié)構(gòu)
9.2　視圖控制器類
9.3　TopicTableDataSource類與TopicTableDelegate類
9.4　通過已有的視圖控制器建立新的控制器對象
9.5　提問列表的數(shù)據(jù)源
9.6　接下來的任務(wù)
第10章　整合所有部件
10.1　完成應(yīng)用程序的工作流程
10.2　顯示用戶頭像
10.3　收尾與清理
10.4　發(fā)布應(yīng)用
第11章　為測試驅(qū)動開發(fā)進(jìn)行軟件設(shè)計
11.1　針對接口進(jìn)行設(shè)計，而不要針對實現(xiàn)
11.2　用命令代替查詢
11.3　簡潔而專注的類與方法
11.4　封裝
11.5　使用比重用更好
11.6　測試并發(fā)代碼
11.7　別耍沒有必要的小聰明
11.8　優(yōu)先選擇寬而淺的繼承體系
11.9　綜述
第12章　在既有項目中運(yùn)用測試驅(qū)動開發(fā)
12.1　第一個測試用例是最重要的
12.2　通過重構(gòu)使得代碼更易于測試
12.3　編寫測試使得代碼更易于重構(gòu)
12.4　真的需要寫這么多測試用例嗎
第13章　測試驅(qū)動開發(fā)展望
13.1　使用一系列輸入輸出值構(gòu)建測試用例
13.2　行為驅(qū)動開發(fā)
13.3　自動生成測試用例
13.4　自動生成能夠通過測試的代碼
13.5　綜述

章節(jié)摘錄

第1章 軟件測試與單元測試簡介要想最大限度地從單元測試中受益，就必須理解它的目標(biāo)及它是如何改進(jìn)軟件開發(fā)過程的。在本章中，讀者將會學(xué)到一些通用的軟件測試知識，這些知識也適用于單元測試。這一章也會講到軟件測試的優(yōu)點和缺點。1.1 軟件測試的目標(biāo)很多軟件項目的目標(biāo)都是盈利，實現(xiàn)這個目標(biāo)的通常方式即通過應(yīng)用商店來出售軟件或者以其他方式授權(quán)給用戶使用并收取費用。那種為了程序開發(fā)者內(nèi)部使用所制作的軟件，則會通過提高某個業(yè)務(wù)流程的效率，減少該流程所耗的時間來間接地盈利。如果通過提高業(yè)務(wù)流程效率節(jié)省的成本大于開發(fā)該軟件的花銷，那么這個軟件項目就是盈利的。開源軟件的開發(fā)者通常以出售“支援服務(wù)包”（support package）來獲利，他們也會使用自己開發(fā)的軟件，在這種情況下，前面的論斷依然成立。所以說，軟件開發(fā)經(jīng)濟(jì)學(xué)的基本原則就是，如果某個軟件項目的目標(biāo)是盈利—不管是向客戶出售最終產(chǎn)品還是供開發(fā)者內(nèi)部使用，那么它要想成功地達(dá)成此目標(biāo)，必須創(chuàng)造某種高于軟件制作開銷的價值才行。筆者也知道這并非一個具有非凡意義的論斷，不過可以將它推及到軟件測試領(lǐng)域中。如果軟件測試（也叫做“質(zhì)量保證”（Quality Assurance， QA））是為了支持軟件項目，則它必須對實現(xiàn)盈利有幫助才行。這一點很重要，因為它對軟件測試做出了限定：如果軟件測試開銷過大，導(dǎo)致項目虧損，那么這種測試就不適合去做。不過對軟件進(jìn)行測試可以保證產(chǎn)品能正常運(yùn)行，而產(chǎn)品又包含了客戶所需的功能。如果你不能展示這些功能的價值，那么客戶就不會購買這個產(chǎn)品。注意，測試的目標(biāo)是證明產(chǎn)品能夠正常運(yùn)行，而不是發(fā)現(xiàn)bug。軟件測試是在做“質(zhì)量保證”，而不是“質(zhì)量介入”。查找bug通常是個壞主意。為什么呢？因為要修復(fù)bug就必須有開銷，而這部分資金本來是付給開發(fā)者的，讓其一開始就寫出無bug的軟件，現(xiàn)在卻被浪費了。在理想的情況下，大家可能會認(rèn)為開發(fā)者只需寫出無bug的軟件，通過快速的測試確保它們沒有問題，然后將其上傳到iTunes Connect賬戶，就可以坐等財源滾滾而來了。不過別急，這么做也會以另一種方式導(dǎo)致同樣的問題：在測試軟件之前，需要多長的時間來編寫100%無bug的軟件呢？這樣做的開銷是多少？這么說的話，合適的軟件測試方案看起來是一種折中：既要保證對軟件開發(fā)進(jìn)度有一定程度的控制，又要在工程開銷許可的范圍內(nèi)進(jìn)行一定程度的檢查，以確保產(chǎn)品確實能夠正常運(yùn)行。這種平衡應(yīng)該著眼于將所發(fā)行產(chǎn)品的運(yùn)行風(fēng)險降低到一個可以接受的水平上。所以說，“最具風(fēng)險的組件”，也就是那些對于軟件的運(yùn)行至關(guān)重要的組件或者那些最有可能隱藏bug的組件，應(yīng)當(dāng)首先測試，然后測試那些風(fēng)險稍低的組件，依次測試，直到你覺得所有剩下的風(fēng)險因素都不值得再投入時間和資金去測試為止。最終的結(jié)果應(yīng)該是讓客戶看到軟件實現(xiàn)了預(yù)期功能，從而值得為此付費購買才對。

編輯推薦

《測試驅(qū)動的iOS開發(fā)》為Amazon五星級暢銷書，作者權(quán)威，在全球iOS/Mac開發(fā)者社區(qū)享有盛譽(yù)！完美地展現(xiàn)了測試驅(qū)動開發(fā)方法與iOS開發(fā)的結(jié)合，能使iOS開發(fā)者在產(chǎn)品需求、軟件設(shè)計、測試有效性與開發(fā)效率之間達(dá)成達(dá)到很好的平衡。

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

---

    測試驅(qū)動的iOS開發(fā) PDF格式下載

---