TDD真是個神奇玄妙的東西

不過我發現"我們的系統是ui與資料庫為主，很難寫純單元測試"的說法，是對TDD準備程度的一個指標。即使用了Mock framework讓那些Test Case的行為符合單元測試，他也還不算會TDD。其實大多數關鍵都應該在POJO，問題在怎麼看出來。

yao_h: 因為沒學過DDD的關係

如果 TDD 是需要經過歲月累積才有感覺。我覺得其實不用 TDD。可以先寫程式再寫 test。先給新手看一些老手的 test case pattern 讓他們模仿就好。

ihc: 我沒有試過，有機會會想想賽大師的經驗。我目前的做法是反向操作，儘量找出常見的可善用TDD而沒善用的例子（通常是ui或SQL相關）來說明。不過成效還不明顯。

XMS 裡面常看到，TDD 產生的 Service 實際上沒用到。結果 test case 測的是沒用到的，用到的反而沒測。

這倒不能說是 TDD 的錯，一方面是因為沒有禁止在前端 controller 下 query。不過 TDD 的門檻是高點。特別是那些網頁長相已固定的更不需要 TDD。

我是不認為TDD可以當testing的依據。TDD是design，如果需要自動測試，應該另外做。舊code補test case很討厭的。一開始如果TDD程式碼根本不會長那樣了。不過補test case如果是為了測試，不如使用Selenium。

有些地方還是很適合用 test case 測試的。但我同意 TestNG 作者的看法。只需要測 1x% ~ 2x%

印象中我幾乎沒做過 design。也不覺得有此需要。怎會如此?

我的做法是以 top down 的方法從外面寫到裡面，其中經歷多次而頻繁的 refactor。TDD 對我這種過程好像幫助不大?

從外面寫到裡面，這不算是設計class外觀和行為嗎？

完全沒用 TDD 啊。

應該說是 UI driven design。

TDD 問題是。為了驗證需要而去加一些沒用的 method。例如 : 為了驗證 insert() 有效加入 list() 並 assert size 多了 1。但實際上前端列表可能根本沒有 list 全部。只有 listValid() 和 listExpired()。

寫 test 時無法預想到這些。如果 UI driven。就不用預想如何驗證。先寫出所有 method 再依現有 method 考慮如何驗證就好。