今天想要講的題目是TDD，Test-Driven-Development 測試驅動開發

看到這個名字顧名思義就以測試為出發點來作為開發，其實這個概念很久以前我就有看到，只是一直沒有太多關注這塊，這次之所以想提是最近別人在使用TDD開發且小有心得，所以才來研究一下

這個之前想先提及
Unit Test
Integration Test

Unit Test

小範圍的測試，針對單一功能的測試

Integration Test

針對所有流程的測試

那麼我認為TDD其實在兩個Test的範疇都是可以使用的

TDD (Test-Driven-Development)

在TDD的階段會有三個狀態

• Red: 測試失敗
• Green: 測試成功
• Refactor: 重構

Red 測試失敗

首先寫一個測試
你必須先驗證這個測試的結果是否是會失敗
如果都是成功的話，那麼這個測試毫無意義
當有測出測試失敗，那麼恭喜可以進到下一個步驟

Green 測試成功

可以快速寫下一個能夠Work的function來進行測試
同樣的測試通過代表代碼是正確無誤的

Refactor 重構

當你的程式碼可以通過測試的時候，並不代表他是一個好的程式碼
所以會需要你來進行優化，即重構的流程
重構後，會需要再跑一次測試，如果測試通過代表你的流程沒有問題
如果重構後測試不通過，代表需要再重新梳理邏輯

TDD的核心

透過概念的轉換
原本大多數人都是寫完程式之後再來思考所謂的測試
所以需要測試時，就有可能大量改動原本的Code

但TDD是先透過測試開始發想整個功能的流程，再進一步寫程式
可以確保如果測試通過後，每次出來的結果都會正確的

不過看了TDD也看了反TDD文章
反對TDD，也不是完全無理性反對，是希望在某些狀況下
大家都能理性思考這個東西對於寫程式碼到底有沒有用
到底一個繁瑣的測試，真的能夠幫助除掉所有的Bug，還是造成程式上的效率問題
那些低級的錯誤，如果修復了一個，就不再出現了，那麼我花費那麼多時間寫測試的成本又要怎麼去計算
我想這個都是大家理性思考後，能夠在各自的專案上發現的東西。

參考網址：

https://medium.com/fcamels-notes/test-driven-development-%E8%A7%A3%E6%B1%BA%E4%BA%86%E4%BB%80%E9%BA%BC%E5%95%8F%E9%A1%8C-%E6%88%96%E6%98%AF%E8%A3%BD%E9%80%A0%E6%9B%B4%E5%A4%9A%E5%95%8F%E9%A1%8C-937db879f695

http://www.yinwang.org/blog-cn/2016/09/14/tests

https://medium.com/@ji3g4kami/unit-test-%E6%95%99%E5%AD%B8-ba39e54fcbc5

https://medium.com/%E6%88%91%E6%83%B3%E8%A6%81%E8%AE%8A%E5%BC%B7/tdd-test-driven-development-%E6%B8%AC%E8%A9%A6%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC-%E5%85%A5%E9%96%80%E7%AF%87-e3f6f15c6651

https://ithelp.ithome.com.tw/articles/10255529

https://tw.alphacamp.co/blog/tdd-test-driven-development-example