TDD 是測試驅動開發Test-driven development 的縮寫，它所提倡的核心概念就是，先寫測試再開發功能的做法，用這個做法來解決遇到的問題，不禁讓人聯想到『限制理論』中的瓶頸，而解決瓶頸最快的做法就是去『遷就』瓶頸。
軟體測試最痛苦的點就是，測試這件事情並不會很明確的被放在需求中，所以開發者的任務也就只有完成需求，這樣也就導致了程式架構會有『可測試性』不佳的問題，而從限制理論的觀點來看，TDD的確是一個遷就瓶頸，解決問題的好做法，需求不但被滿足了，也被測試給保護了，因為是從測試的角度出發所以連可測試的問題都一併解決了。
這也是我常常在想，為什麼自己開發產品的時候速度可以非常快，而公司在開發產品的時間往往是數十倍以上，因為自己開發的時候，自己對目標價值的了解非常明確，自己知道要滿足什麼樣的需求，隨時可以快速的調整去遷就瓶頸，比如可能某個程式流程不好做，我馬上可以調整使用流程，來達到一樣滿足需求，但程式開發效率卻提高好幾倍的做法，但這在公司之中根本不可能，但換個角度來說時間的花費對公司來說可能也不重要就是(非瓶頸
不過在時代的進步紅利下，現在在JVM也可以選擇JMockit這個神兵來解決『可測試性』不佳的問題，在Android上的話也可以搭配Robolectric 來使用。
至於因為整個軟體流程E2E，所遇到的不可測試性問題，例如創新帳號，如果整個流程沒有測試思維也會變得困難重重，如:驗證機制怎麼辦?測試完成後是否能刪除帳號?怎麼刪?這些問題都會牽扯到好幾的團隊，如果一開始測試都不在需求之中，這個問題就會變得很棘手，我的建議就是做自己那端的整合測試，App的話就Mock回來的API就能測試自己想測的了，而Server則是Mock Database回來的資料，雖然也可以藉由Docker這類的虛擬化技術來解決，但整體的CP值來說，還是配合Mock的整合測試最棒!
最後希望你帶走知識的同時，也能留下一兩句的心得與我們分享或是幫我們按下+1並分享到FB
軟體測試最痛苦的點就是，測試這件事情並不會很明確的被放在需求中，所以開發者的任務也就只有完成需求，這樣也就導致了程式架構會有『可測試性』不佳的問題，而從限制理論的觀點來看，TDD的確是一個遷就瓶頸，解決問題的好做法，需求不但被滿足了，也被測試給保護了，因為是從測試的角度出發所以連可測試的問題都一併解決了。
這也是我常常在想，為什麼自己開發產品的時候速度可以非常快，而公司在開發產品的時間往往是數十倍以上，因為自己開發的時候，自己對目標價值的了解非常明確，自己知道要滿足什麼樣的需求，隨時可以快速的調整去遷就瓶頸，比如可能某個程式流程不好做，我馬上可以調整使用流程，來達到一樣滿足需求，但程式開發效率卻提高好幾倍的做法，但這在公司之中根本不可能，但換個角度來說時間的花費對公司來說可能也不重要就是(非瓶頸
不過在時代的進步紅利下，現在在JVM也可以選擇JMockit這個神兵來解決『可測試性』不佳的問題，在Android上的話也可以搭配Robolectric 來使用。
至於因為整個軟體流程E2E，所遇到的不可測試性問題，例如創新帳號，如果整個流程沒有測試思維也會變得困難重重，如:驗證機制怎麼辦?測試完成後是否能刪除帳號?怎麼刪?這些問題都會牽扯到好幾的團隊，如果一開始測試都不在需求之中，這個問題就會變得很棘手，我的建議就是做自己那端的整合測試，App的話就Mock回來的API就能測試自己想測的了，而Server則是Mock Database回來的資料，雖然也可以藉由Docker這類的虛擬化技術來解決，但整體的CP值來說，還是配合Mock的整合測試最棒!
最後希望你帶走知識的同時，也能留下一兩句的心得與我們分享或是幫我們按下+1並分享到FB
留言
張貼留言
有什麼想法歡迎跟我們分享