iOS APP iOS Test-Driven Development by Tutorials free section 學習筆記-前言與概述

tags: TDD day

前言

上週參加iOS Developer 高雄小聚，有聊到 Rxswift 的學習方法。Rxswift 學習是有一定的難度與門檻的，所以我在學習上撞得滿頭包，因此我放慢自己的步調，梳理一下如何達到學習RxSwift。

為什麼要學 unit test?

事實上我在學習 Rswift的過程中碰壁了，我們都知道Rxswift 可以有效防止 Callback hell。

學習上的難點，知其然而不知其所以然

但是我的對於 Callback hell的感受不夠深刻，這是因為 "Rxswift 解決的問題" 是二手資訊，並不是我親自解決的。也就是說我知道了解決問題的方法卻不知道問題本身。這成為了我學習的阻礙。

所以我學習TDD？

為了學習Rxswift而學習TDD或許是繞道，但是為了讓自己最快到達高內聚低耦合的目標，學習 TDD 是不錯的方法。

讓程式碼 testability

因為 TDD 這個 software process，會幫助我們思考如何讓測試目標有 testability，因此在開發過程中會把程式拆的很細。

體會設計架構的意義

將程式碼職責分離，在分離到極致的過程中，不難發現程式碼會趨向現在流行的設計架構。這幫助我們在學習上，更容易體會設計架構的意義。

因此我決定了解TDD的開發流程，並實際開發一個簡易的App。小聚時，有位資深工程師推薦了一本書：

連結

What Is TDD?

TDD 是 Test-driven development 的縮寫，他是一種迭代開發軟體的方法。

圖片來源

這邊必須要特別注意“迭代”這兩個字的意義。

TDD有四個steps:

1. Write a failing test 寫一個會失敗的測試
2. Make the test pass 通過測試
3. Refactor 重構
4. Repeat 重複

在使用 TDD 你必須非常清楚

良好的測試可確保您的應用按預期運行。但是，並非所有測試都“good”。為進行測試而編寫測試不是一個值得的練習。相反，好的測試是失敗的，可重複的，快速的運行和可維護的。

正確的 TTD 測試守則：

1. 寫一個 failing test

第一步是編寫一個失敗的測試。根據定義，這證明測試是失敗的。不能失敗的測試不是很有用。相反，它們浪費了寶貴的CPU time。

2. 在允許您編寫新測試之前，所有其他先前的測試都必須通過

在允許您編寫新測試之前，所有其他先前的測試都必須通過。這樣可以確保您的測試是可重複的：您不只是運行您正在處理的單個測試，而是不斷地運行所有測試。

3. 測試時間最好是一秒鐘或更短的時間

通過頻繁運行每個測試。您的所有測試都需要幾秒鐘的時間-最好是一秒鐘或更短的時間。

4. 每一次refactor同時更新生產和測試代碼

重構時，您將同時更新生產和測試代碼。這樣可以確保您的測試得到維護：您一直在不斷更新它們。

5. 必須遵守流程

通過並行並行編寫生產代碼和測試，可以確保代碼可測試。如果您要在完成代碼後編寫測試，那么生產代碼很可能需要大量重構才能進行完全的單元測試。

你該測試的對象是什麼？什麼不該測試？

更好的測試覆蓋率並不總是意味著您的應用程序會得到更好的測試。有些事情應該測試，而其他則不應該。
我們需要秉持的四不原則：

• 做代碼寫入測試，不能以自動化方式捕獲，否則。這包括類的方法中的代碼，自定義getter和setter以及您自己編寫的大多數其他代碼。
• 不要為生成的代碼編寫測試。例如，為生成的getter和setter編寫測試是不值得的。Swift可以很好地做到這一點，您可以相信它的工作原理。
• 不要針對編譯器可能捕獲的問題編寫測試。如果經過測試的問題會產生錯誤或警告，Xcode會為您抓住它。
• 不要為依賴代碼編寫測試，例如您的應用程序使用的第一方或第三方框架。框架作者負責編寫這些測試。例如，您不應該為UIKit類編寫測試，因為UIKit開發人員負責編寫這些測試。但是，您應該為其自定義子類編寫測試：這是您的自定義代碼，因此您有責任編寫測試。

總結

TDD的最令人詬病的地方是它花費的時間太長。但是，事實是，與根本不編寫任何測試相比，他花費的時間更少。
開發的實時成本不僅僅是編寫初始的第一版生產代碼。它還包括隨著時間的推移添加新功能，修改現有代碼，修復錯誤等。從長遠來看，遵循TDD所花的時間要比不遵循它要少得多，因為它產生的代碼更具可維護性，而且錯誤更少。

實作過程