TDD (測試驅(qū)動開發(fā))
測試驅(qū)動開發(fā)不是新鮮的概念，但是在國內(nèi)的客戶端開發(fā)，甚至有些服務端開發(fā)中并沒有盛行，其原因也多。我們在寫程序時，最喜歡或習慣做的事情，就是編寫一段代碼，然后運行觀察結果是否正確，如果不正確就檢查錯誤，或者打斷點、print跟蹤調(diào)試程序并找出錯誤，然后再次運行查看是否與預期一致。
TDD 是一種與普通邏輯思維相反的做法， 我們一般能想到的是先編寫業(yè)務代碼，然后再針對業(yè)務代碼編寫測試代碼，來驗證最終結果。而TDD 正好與之相反，在TDD 的世界中，我們應該首先根據(jù)需求編寫測試代碼，然后再根據(jù)測試來編寫業(yè)務代碼，而這也是違反傳統(tǒng)軟件開發(fā)中的先驗認知的。但是我們可以舉一個生活中的例子來說明TDD的必然性：我們在定制合身的西服和婚紗的時候都會對身體的尺寸來進行測量，然后再根據(jù)合適的尺寸進行制作，最終制作出最合身的衣服。而如果直接根據(jù)某一個標準碼來進行制作，可能由于身高或一些因素，最后還需要重新測量并且對衣服進行修改。TDD 的好處不言而喻。因為總是先測試，再編碼，所以你的所有代碼的公共部分都應該含有必要的測試。還有，在測試代碼中是需要引入使用業(yè)務代碼的，因此在編寫業(yè)務代碼之前你有一次可以深入思考和實踐如何使用這些代碼的機會，這對提高設計和可擴展性有很好的幫助。試想一下如果是你測試都很難寫的接口，別人在使用起來是不是會很糾結。在有測試的前提下，你可以有目的有方向的編寫業(yè)務代碼。還有，因為有測試的保護，你可以放心的對原有代碼進行重構，而不必擔心破壞這些邏輯。
BDD （行為驅(qū)動開發(fā)）
在iOS 中有專屬的傳統(tǒng)測試框架 XCTest，使用簡單，但是在書寫性和可讀性上都不太好。在測試用例太多的時候，很難搞清楚某個測試到底是做什么，因為所有的測試都是由斷言來完成，很多時候斷言的意義也并不是特別的明確，還有，每一個測試的描述結果都是被寫在斷言之后，夾雜在測試邏輯中，很難尋找，并且使用XCTest 難以將對象或方法進行 mock 或者stub， 這是在測試中很重要的。BDD 提倡是通過將測試語句轉(zhuǎn)換為類似自然語言的描述，開發(fā)人員可以使用更符合大眾語言的習慣來編寫測試，這樣我們在可讀性會高很多，并且便于修改。
一個典型的BDD 的測試用例包括完整的三段式上下文， Given..When..Then，或者說是一個 Arrange.. Act.. Assert 三部曲。BDD 在很多語言中都有支持的庫，使用規(guī)則和語法都大同小異，在Swift 中我們可以使用Quick 和 Nimble 結合來編寫測試。
如何編寫測試
如何通過Quick 和Nimble 來編寫Swift 的單元測試，這里有比較詳細的文檔說明。
測試覆蓋率
在Xcode中集成了很多有用的工具，測試相關的也不例外，我們可以通過設置，在每次測試完成之后，就可以直接查看測試覆蓋率的統(tǒng)計。
在運行測試Cmd+U之后，我們可以看到測試覆蓋率的統(tǒng)計。
