其實我覺得寫 test 對於 design 起不到任何協助作用。可以找到任何一個人，平常無法做好 design，用了 TDD 就能做好，或者大大加快 design 速度的例子嗎?

Test case 也無法成為設計規格。尤其那些用 Mock 寫出來的外星文。工程師看了都累，何況非工程師。規格只能用文字表達。

等等等等 TDD = test driven design != test driven improvement of the ability of design XDDDD

如果 TDD 不能協助 design, 為何要 TDD?

看起來 TDD 可以一魚三吃， design,test, 規格描述。但結果它不算什麼 design 方法，不是最好的測試流程，也不成為規格。

它可以描述design 所需滿足的情境

但不能讓design 的功力進步

描述的話，我覺得 UI，use case, user story 都比較好。有了它們之一就能直接 coding 了

嗯，UI, use case, user story 的顆粒度有時不能細到和你的設計一樣怎半? 而且沒有test case 如何自動驗證? (還是塞大師覺得用integration test 足矣?)

我覺得沒有標準答案，看在什麼情況

賽大師能舉個實例嗎

我個人很不喜歡太依賴Mock的test case風格。至少在Java不適合，那會讓test code讀起來很彆扭

喔我是指不喜歡太依賴Mock Framework。

丁有一次跟我說 那是靜態語言的限制 Ruby的Mock Framework就比較漂亮 不過我沒研究就是了

我不是說不用 test case。而是先 coding (至少有框架) 再 test 才符合人類最直接的思考方式。應該是 design drive test。

在設計過程中，常會面臨策略選擇。如，有一種 SOP 文件，該文件包含多個流程組合成圖。

沒有實例比較難談。以個人經驗而言，也沒有堅守TDD，很多情形就是不容許。不過我幾乎98%遵守的是"client-code-driven"就是不先實作目標class，而是先假設class已經實做好，把client code寫好，然後再實作目標class。

頁面上會顯示流程圖， user 點選某步驟會顯示那個步驟的具體操作。每個步驟又有一些邏輯，如果怎樣，跳到哪一步。

寫client code也是設計。client code如果是test case會更好，因為行為會規範得很完整

這樣，我們該把整個 SOP cache在 memory。還是user 每次 click 都重新把那筆從 db 讀出?

策略選擇不同，常會影響數支java。程式結構也可能不同。

與外部的architectural的決策 不是TDD辦得到的

常常開發一項功能，需要面臨好幾個策略選擇。選擇策略常常不是為了功能。而是 performance 和 可讀性的平衡。

我在開發過程常會有數次的策略改變，此時就有大量 refactor，這過程要保持 test 正確會煩死。

這個例子 TDD可以做的是(用直接的思維講 賽大師不要笑)就是有個Forward的class。也許還有個status或是step的class。他們就會負責各種顯示訊息以及隱藏/打開的選擇，下一步可以是哪些地方。這樣的POJO其實本身就很複雜的。可以用TDD來規範各種情形

如果太複雜 可能要加上knowledge level

大部分的程式開發都會因策略改來改去。如果這些不能用 TDD，能用 TDD 的其實很少。

加上頁面/cache當然會更複雜，不過我自從先把POJO部分釐清再處理其他部分以來，發現一個效益，就是POJO能涵蓋的事情比我以前直覺以為的要多

TDD多少會鼓勵系統Miximize POJO，minimize其他部分

上述的Forward, Status class如果不是POJO而放在整合測試，會變得指針對現有流程設計<

對POJO TDD會鼓勵我們寫出通用的設計，而通用的實做往往比較乾淨。

需要有 Step 物件的想法應該不是從 TDD 來的吧。但是我覺得，需要有個 class 叫 Step 這個想法正是 design。有了 design 之後要先產生 test 比直接寫 code 需要更高的技術與邏輯，而且似乎沒有額外的優點。

是的 找出Step是設計。不過只是設計的一部分，完整的設計是要描述行為。

寫test case甚至可能包含分析：光是把Step跟Forward的互動寫成test case，也可能會遇到一些行為是SA沒想到的。或是你想到比SA更直覺的規則。

POJO 應該多放點東西沒錯。但為何 TDD 能協助人把邏輯放在 POJO? 我個人用的通常只是如 : 儘量不寫 public static final 常數。把這些是儘量放在同一 class 做。儘量能寫帶邏輯的 enum 等。

我也不知道為什麼TDD 能協助把邏輯放在 POJO。遇到網頁流程，先抽象出POJO 做好了再來想Session還是DB或是反過來先處理架構再把流程邏輯放進來，程式碼好像就是不太一樣。

Step 的結構和會因策略而有變喔。例如，Step 該不該有 getNextStep()，還是我們只用 sop.getStep(i)。先寫了 test 就連 test 也要改來改去。

Test 需要有驗證的天性，強迫一開始設計就要有更全面的思考。例如，寫 insert 時就要去想會不會有 list()，這樣門檻更高。

有IDE幫忙 refactor通常連test都一起自動改。如果test紅了就會回想起原來有這條規則在，新設計還需要需要嗎？沒有test時這些要全憑腦力，debug比較累。

另外是，我對 test 的看法是，只需要測重要的 1x% ~ 2x% 。其它靠整合測試。程式結構穩定後，我才有辦法判斷哪裡重要。先寫 test 可能會寫太多 test 浪費時間。

有很多 refactor 不是 IDE 能做的。例如把 step.getNext() 改成 ，sop.getStep(i)

其實以上只是個人經驗，有可能我在賽大師的處境會比賽大師更反對test case。 我是覺得TDD有點像crc card的效果，先不要斷言如何設計，而是摸索怎麼設計最能簡單地符合各種情境。

當然我也不是所有程式都寫好才開始 test。假設某個 POJO 裡放了蠻確定的 method, 馬上可以先寫它的 test。不過我不是 client code first。感覺那樣比較間接。我把method 放在某物件中不是因為 client 想這麼呼叫。只因那是它的責任。

不管用不用 TDD，我的程式成型前通常都會改了又改。一次就定位我做不到。不知費教授是否會如此，如果有人不會這樣我只能說太崇拜了。

可惜不太有機會和費教授 pair programming 了。

題外話，mock 某些時候還是很好用的。jMock 很醜。我覺得Mockito 好些。

Mockinto我也久聞大名。有機會會用用看。我當然會改來改去呀，即使是TDD時也改得亂七八糟。前一個test case剛做完，到這一個test case就改設計。有時是因為Agile的simple design ，但是常常純粹是個人糊塗，設計錯了。

英文文法! 果然是 kiwi !

好吧我confess 一下，我也不是全部測試寫於程式之先，有時手癢一下就從本尊很high 的寫起了，要先寫test 的狀態通常是我覺得程式規格對我來說不那麼好理解的時候

我通常最外層 Service 有可能 test first。(不過通常也不會，因為我未必每個都測。) 內部 POJO 互動就不關 TDD 的事了。

像 DocumentService.addDocument(doc) {

DocumentDao.addDocument(doc);

docIndexer.addDocument(doc);

}

這種東西我覺得沒有測試的價值。

ihc:TDD的話，也許Service根本不是長這樣。

cookiemouse:握手。只是，程式規格我好像很少沒test case就很清楚。

ihc: 覺得補test case 和TDD是完全不一樣的活動耶。雖然好像只是一先一後的差別，但是做出來的東西好像會不同。

TDD 的話，不會有 Service 這一層嗎? DocumentService:addDocument 大概會長成怎樣的呢?

很難說耶。我經驗不多，好像沒有TDD弄出service層過。

意思是直接在 Struts Action 或 jsp 呼叫 POJO? 有 Dao 嗎?

有的專案有開發規範 要乖乖做。沒有規範的就...嘿嘿嘿

如果新增一分文件，文件只有簡單的 title, body。新增後文件要被存進 db 並建立索引。大概會寫成什麼型式呢?

這個我應該不會寫unit test ，會想用integration test 串流程的時候順便測XD

除非，index 時有啥咪撇步，需要一些tricky 的設計 --> 比方說要建成suffix tree 再一個一個branch 裏斷字之類的balah balah，因為比較複雜所以要寫

其實我覺得，TDD 的觀念和整合測試還比較親。單元測試細節太多。特別是 mock framework 測試法。程式還沒寫之前怎麼會知道誰該被 mock

如果用 TDD 的做法，先有 test 再寫 code。上述的例子就也得寫 test case 了不是嗎? 程式還沒寫之前，怎麼會知道程式只有兩行，簡單到不用測呢?

靠輕驗~

經驗好的人可以猜到。但是先寫 code 的話練猜都不用猜。該如何就如何。不是更簡易嗎? 我還體會不出先寫 test 和先寫 code 能產生如何不同的設計。