測試驅動的iOS開發（簡體書）

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

GrahamLee，資深安全顧問與iOS/Mac開發專家，在全球iOS/Mac開發者社區中享有盛名。多次受邀在VoicesThatMatter、NSConference、AssociationofCandC++Users以及Qcon等國際技術會議上展示高質量的Cocoa軟件工程實踐。在軟件測試領域有深厚的積累和實踐經驗，從６年前主管一個基於GNUstep的服務器應用程序的測試開發工作開始深入研究OCUnit與單元測試技術。在研究iOS開發前，曾為OSX、NeXTSTEP及其他類UNIX系統開發過應用程序。他還是一位經驗豐富的技術作家，著有《ProfessionalCocoaApplicationSecurity》一書。．

《測試驅動的iOS開發》為Amazon五星級暢銷書，作者權威，在全球iOS/Mac開發者社區享有盛譽！完美地展現了測試驅動開發方法與iOS開發的結合，能使iOS開發者在產品需求、軟件設計、測試有效性與開發效率之間達成達到很好的平衡。

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

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

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