測試開發-TDD、BDD、DDD，易懂難做
最近在看測試開發的相關書籍
越看越覺得很難做
書中說明的範例都太漂亮了
配上測試開發的說明就是完整的流程
完美又無懈可擊
但是BUT
在現實中所遇到的真實狀況
會很複雜又麻煩
還有資料庫的操作
跟最討厭的需求不斷改變
在一開始寫CODE時
測試很難寫出跟最後產出的CODE相配
所以
我改變做法
已所知的需求跟目的下
先寫出第一版可以執行的CODE
確認程式是正確而且可以執行的
當MVP交付
儘快提供給真正的USER做畫面、功能、報表、資料的確認後
再依第一版的CODE去翻寫出TEST CODE
然後再依TEST CODE寫第2版可上線的CODE
如果真正的USER不做確認就停止開發
直到USER回覆
這樣做的好處是把USER當做開發人員
寫出USER真正想用的功能
來減少需求上的理解錯誤
加快驗收的速度
每寫好1個功能就RELEASE給USER用
要求每週交付給USER
也要USER在一週內回覆
(不要瀑布/隕石開發)
當USER確好所有系統功能都正確後
就進入重構CODE
這時才寫TEST CODE
並修正資料庫
然後寫出完整最終可上線的版本CODE
通常
依經驗來說
至少要寫到第3版後
USER的需求跟系統的核心才會完整確認
在重構時也不是單純的簡化CODE
而是考慮到擴充性
把CODE改的更有彈性
整個開發過程不只放在測試開發
而是把USER當成開發的一份子
直接拉進開發流程當測試驗收
跟測試開發比較
USER更為重要
千萬不要放過USER
搞錯目標、重寫CODE代價太大了
自我LV~