從事開發軟體至今，一直以來都是有Bug就改，有需求就修，但是直覺式的思考讓我在修改Bug/修改需求的時候也常讓我越改越多Bug，這讓我反思，要如何才能夠提升軟體開發的水準呢？究竟是開發的水平不足，還是有更好的方法沒有採用呢？
身為一個Android開發者，清楚了解Android裝置是如此多，而每間公司的發行的Android裝置，雖然都是基於Android平台來開發，常常遇到這台裝置沒問題，同樣的解法在別台裝置卻有問題。到底要如何涵蓋所有可能發生的情況呢?
測試驅動開發(Test-Driven Development— TDD)
測試驅動開發(TDD)，是一種先思考如何完成測試的一種開發方式，這種開發的方式與直接編寫程式碼的差別在於，當我們是以測試為導向時，所有實作的方法都會有相對應的單元測試。換句話說，功能實作後才去編寫單元測試，就是先射箭再畫靶。
TDD 三定律
(http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd)1. You are not allowed to write any production code unless it is to make a failing unit test pass.(你不能編寫任何程式碼，除非你的單元測試失敗)
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. (單元測試已剛好正確測試一個失敗項目時，你不允許編寫更多的單元測試；編譯失敗也算無法通過)
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. (單元測試可以正確測試一個失敗項目時，你不允許編寫更多程式碼)
由上方的定律可以感受到，程式碼的編寫應該是能少盡量少，不需要多餘的程式碼，每一行程式碼都應該通過單元測試，這邊可以呼應敏捷開發(Scrum)所提倡的"以終為始"，這裡的"終"代表著完成一段程式碼搭配一個單元測試，那"始"自然就是朝這個方向邁進。
產品開發階段，很容易落入一個陷阱，就是只完成表面上所看的到的事情，而忽略細節，這句話怎麼說呢？
以開發相機App為例子，這些事就是(1)打開相機，(2)拍照，(3)儲存相片。往往實作完這些功能之後，稍做測試，該功能就認定正常。但是若是以TDD做為開發的方式，則會思考打開相機會發生什麼事，有什麼錯誤需要被處理，除了思考以外，並且還必須編寫單元測試以供驗證，如此一來便可以對於該解法更有信心了。
測試Android App吧!
在Google I/O 2017中，有一場演講是討論Test-Driven Development 在Android如何實作，有興趣的朋友可以上去看看。
下方的圖片為測試金字塔，由上至下為UI Tests(Large Test), Integration Tests(Medium Test), Unit Tests(Small Test)。
花費：UI Tests>Integration Tests > Unit Tests
速度：Unit Tests > Integration Tests > Unit Tests
Small Test:
可以與產品系統隔絕的單元測試，通常會模擬每一個主要的元件並且可以快速的執行。
Medium Test:
整合多個元件在真實裝置或是模擬器上的測試。
Large Test:
採用完整的UI工作流程來整合及執行UI測試。確保使用者在真實的裝置或是模擬器上如預期般的操作。
小結
為了讓開發出來的軟體更有品質，更符合自己/客戶的需求，發行前勢必都必須要測試，初入軟體業時，公司有專門的QA部門在測試軟體，所以在正式推出前，都必須要經過QA的檢驗，若是發現有任何異常，或是不符需求，則就會被退回修改後重新發一版。這樣不僅會浪費許多時間，許多可以在提交之際就可以發現的問題如果到了最後一刻才被發現，影響的可不是自己一個人，有可能是影響整個專案的進行。
對App開發來說，測試絕對是有其存在的必要性的，那麼我們該如何測試我們的App呢? 我將在下次的文章繼續討論。
謝謝各位，如果有任何錯誤或是任何疑問，都歡迎跟我連絡討論。
