對于Objective-C來說 Unit Testing的價值是什么？
最大的問題是“對于Objective-C來說 Unit Testing的價值是什么？”
服務端的小伙伴會Mock整個數據庫，僅僅為了測試一條類似于“Hello World” 的SQL語句。
在iOS中，你需要如此的仔細嗎？這大概是不需要的。
你需要將單元測試覆蓋到iOS項目中的每一行代碼嗎？這毫無疑問是不需要的。
那么，讓我們來看下，你應該怎樣決定你的測試計劃。
單元測試有兩個目的：
- 首先也是最重要的（從我的觀點來說）它可以幫你保持類的小而精。
- 其次，它可以為你提供自動化測試，這是非常有用的。
為什么我這么說？
如果你嘗試編寫一個類去通過某個API來獲取數據，你會從對它行為的一些猜測來開始開發。
使用這個類，會依賴這些假設。假如你過了幾個月忘記這些假設是什么，那么如果你更改了關于網絡請求的代碼，你很有可能在某個地方改變了之前的邏輯。這些可能發生在你毫不知情的情況下。
你應該通過手動還是自動去測試你的App？它并不意味著你需要將單元測試覆蓋整個APP，但是在發版本之前，你應該測試一些關鍵之處，那么為什么還要通過手動做這些呢而不選擇自動測試呢？
Matt Gemmell 曾經寫過“thou shalt suffer no bugs to ship”（發版時必須不要有任何Bug），我認為他說的很對，并且我也是這樣做的 。他也說到，無論你用哪種機制去保證在發版時沒有bug，你只是需要有一種方法。Unit Tests， UI Acceptance Tests, 或者所有的測試都通過手動解決（但是這將會花費大量時間）。 Unit Test 或者UAT更加迅速。
上面說的所有都是“對于Objective-C來說Unit Testing的價值是什么？”這個話題的開場白。
讓我們來思考一個好的架構的iOS app。它被劃分為三個部分： Model，View，Controller。
我有說 three parts？ 我的意思是 three-ish（暫時沒搞清楚什么意思??）。 App需要API 的調用，你也需要寫網絡請求的代碼。有的時候，代碼會從Model中分離，有時候也會包含在Model中，在可避免的情況下它應該從不包含在View中，或者包含在Controller中（這應該永遠是可避免的）。
View和Controller自檢的相互作用不利于單元測試— 這些地方UAT可以幫你解決這個問題。 這篇文章并不會涉及這些。
橙色的區域是單元測試最有作用的地方。Model和網絡請求代碼中。
你可以很容易的測試網絡請求代碼，去驗證你第一次寫它的時候關于它的假設。如果你的Model比較精煉，你可能不會去測試。然而，這些models可能在任何地方被創建和修改，所以，你應該確保測試這些代碼。
綜上所述：單元測試 Models 和網絡請求代碼。如果你覺得值得，那么用UAT去測試其他的。可能手動測試Views和Controllers更加適合你的工作，特別是在比較小型的app中。
最后，無論你用哪種測試，請記錄它，并且編成文檔。這樣你就可以在發版之前手動測試它了。
