今天不寫code 來談談單元測試
其實關於這個主題應該要擺在更前面的天數比較合適
不過 30天連載 總是不太可控 (其實是拖到今天才想辦法擠出這篇文

在開始之前 先問一個問題
為什麼要寫測試?
因為要確保寫出來的功能符合預期

例如今天PM開一個需求給你 你總不可能code寫完連測都不測就上繳給別人用了吧
... 不對 雖然我真的有見過這種人 但應該算少數

身為一個有責任的工程師 在將程式交給別人測試之前
應該都會自己手動點一點確認功能是不是正常
手動驗證其實也是測試的一種

但是隨著專案越來越大 如果想確保所有功能都正常 那麼測試所需要的時間也越長
其中又有很多是機械式的重複動作
所以呢 身為一個懶的要死的工程師
最希望的當然是每次建置時交給機器自動驗證

所以呢 testing最好一開始就寫 隨著你的程式碼越來越龐大，越來越複雜，有完整的測試代碼就比較不容易擔心程式被改壞。
像昨天的code就靠testing發現有功能跟原本運行的結果不一致

測試金字塔 (source Martin Fowler)

這張圖是提到測試時常會提到的測試金字塔
含意是越下層的測試時間越短 涵蓋範圍越廣 越上層需要花費越多的$$$(設備 人力等等都算) 運行測試所需時間也更長

回到正題 那如果要寫測試該怎麼做呢?
首先android studio可以直接運行許多測試框架
明天會繼續講如何撰寫運行所需時間最短 涵蓋範圍最廣的unit tests

那麼原生的android專案的unit tests一般是運行在 Java Virtual Machine (JVM)上
會比運行在模擬器或實機的espresso快上許多

另外espresso並不是單元測試 而是Instrumented tests
這類的測試主要是來測試一些function的結果是否符合預期

常用的框架是junit4.12
另外如果你的function內包含android原生的物件(ex:content)或方法的話測試會失敗
你可以使用類似mock之類的去模擬那些物件
或是函式內不要引用android的物件

後來延伸的一些架構 部分原因也是因為那些架構較容易進行測試

那麼明天會找個實際的專案開始撰寫unit tests