程序猿求生指南

當我們把unit test一些基本概念弄清楚後，我們進入下一個章節TDD，TDD全名是Test Driven Development，也就是測試導向開發，在還沒寫production code之前先寫測試，聽起來很難想像因為跟我們的開發習慣大異其趣。都還沒有開始寫code是要怎麼先測試呢？其實並會不太難，只要改一下寫code的習慣先看spec規畫interface再來寫production code就可以了。 MVP應用 開發需求：在Main page中的TextView中顯示username欄位，文字屬性16dp，置中，顏色黑色。 假設有一個開發需求如上。這時候尋常的做法就是打開designer的UI圖第一步先把layout檔建立好，然後下一步就在Activity或Fragment裡面寫一個跟server reqeust的function去更新TextView。這個做法很平常，但是如果我們實踐TDD的測試導向開發方法，我們把重點擺在正確的邏輯先寫出來再去寫UI部份，因為UI可能不斷的改變，邏輯可能一確定下來就不會變了(可能啦)。 我建議可以這樣做。第一步，先不要寫layout部份，layout只是先讓自己有一個畫面感覺，先試著把跟UI有關及無關的東西分開來，像是要對TextView操作setText這就是UI有關的部份，而跟server request data的部份就跟UI無關，因為之前說過Unit test無法測試跟UI元件instance有關的部份。 不用管細節實作，先開發介面吧 所以我們單元測試的重點就擺在UI無關的server requst部份。如果採用MVP架構的話，我們要測試的目標就是presenter的function，下一步就是建立一個presenter class把跟server有關的邏輯寫在裡面，在忍不住想要開始寫production code之前先等等，我們再回去看之前的範例，你有沒有發現我們在做單元測試的時候其實都會把presenter裡面用到的物件mock起來，被mock起來的物件其中要怎麼return value或行為都是由該測試單元來定義而不是真的去執行Activity的細節來獲得資訊，也就是在寫測試code的時候不用管presenter細節的實作，我們只要知道function名稱跟回傳型態就可以寫測試...

程式設計師升級必練內功：TDD Kata 測試驅動開發（ Test-Driven Development ，簡稱 TDD）是一種程式開發的技巧，簡單來說就是先寫測試程式，然後才實作功能。具體的流程則是透過 Red–Green–Refactor cycle 的循環： Red – 先寫測試程式，此時因為還沒有實作功能，所以這個測試是會失敗 Green – 快速實作出功能，讓上述的測試通過 Refactor – 重構程式碼，去除多餘重複的代碼，提高程式碼品質，同時維持測試通過 對於開發軟體需要撰寫自動化測試，已經廣泛獲得專業軟體開發者的認同。軟體產品想要走的長遠，就必須為其撰寫自動化的測試程序來確保軟體品質。但是對於是否全然實行 TDD 的爭議則層出不窮，特別是對於 TDD 被當作一種教條的反感。 但無論是否百分之百實行 TDD，筆者都認為學習 TDD 會是一個專業軟體開發者升級的必經過程。透過練習 TDD，軟體開發者可以學習到如何撰寫好的自動化測試，怎樣設計軟體可以更模組化、更容易擴充，以及設計出好用的 API 介面。 那要如何上手學習 TDD 呢？光看理論是不行的，唯一的辦法就是動手做來獲得經驗。要直接利用公司專案練習 TDD 可能會比較困難，一來在不熟悉的情況下會大大拖慢開發速度，二來在有 GUI 和 Multilayered 軟體架構的環境中，導入 TDD 會一次面對太多問題和挑戰。 利用 Code Kata 學習 TDD 因此學習 TDD 最好的方式(沒有之一)，筆者認為就是  Code Kata  形式了。「 Kata 」是日本字「形」的意思，中文的意思是「套路」。而 Code Kata 就是透過一些小型的程式題目進行重複鍛鍊，就像學功夫套拳。不需要 GUI 或複雜的軟體框架，只需要程式語言本身和一個單元測試函式庫，透過全然遵守 TDD 的規範來練習這些題目，內化及提升程式設計能力。 搜尋 Code Kata (或 Coding Dojo: 用 Kata 一起練功的 coding 活動)可以在網路上找到很多  Kata 題目 。這裡茲舉一例：Potter Kata： 有一家書店在賣哈利波特書籍系列，每一本書定價 $100 元。買兩本不同的書可以打5% 的折扣、...