→ guest2008:確實是這樣.類似股票長線派在跟短線派爭論誰獲利,誰方法 05/28 03:14
→ guest2008:正確..黑貓白貓會抓老鼠就是好貓 05/28 03:14
→ guest2008:有些人一個月只要模組增加一點新功能就能領薪水. 05/28 03:19
→ guest2008:有些人是二個月要完成一整個團隊的任務或全部的系統 05/28 03:21
→ guest2008:你是後者.我真的不知道你怎麼還有那麼多功夫可以寫測試? 05/28 03:22
→ guest2008:我提過能被檢測程式檢核到error我真的感到訝異.不可能發 05/28 03:24
→ guest2008:生. 除非說明或文件沒給清楚.不然不可能發生. 05/28 03:26
→ guest2008:上面那句話肯定會被炮轟.很多人要質疑.因為你們沒經驗 05/28 03:31
→ guest2008:但事實就是這樣.我寫的程式也會有bug.但自己會檢測過. 05/28 03:32
→ guest2008:這類的bug.根本就是檢測一次就不會再發生.哪會需要一再 05/28 03:32
→ guest2008:需要重複檢核?還會再發生,那代表你的程式品質真的有問題 05/28 03:33
推 guest2008:我今年已經被兩位好友講我的程式功力退化了.沒有年輕時 05/28 03:41
→ guest2008:猛.但事實我根本沒感覺我真的有退化.我只是程式碼寫更多 05/28 03:43
→ guest2008:但因為執行結果相同.讓大家感覺我怎麼開發用時更多了? 05/28 03:44
→ guest2008:我到底在寫啥?我每一個函數.每個進入點都寫了一大堆檢核 05/28 03:45
→ guest2008:因為累積經驗..一些死人骨頭會怎樣給你亂搞的全都檢核 05/28 03:46
→ guest2008:這樣的方式還需要去寫驗證案例嗎?還不如像我這樣直接把 05/28 03:49
→ guest2008:檢查寫在程式碼內..跟著程式碼走..沒檢核也不會出事 05/28 03:50
推 guest2008:貼一篇趣味文章做結束.讓氣氛緩和一下. 05/28 03:54
→ tkdmaf:我在想。UNIT TEST很單純就是驗證功能的結果。 05/28 07:51
→ tkdmaf:並不需要把他想得太複雜。 05/28 07:52
→ tkdmaf:一個函式，一個方法，依結果回傳TRUE、FALSE。 05/28 07:52
→ tkdmaf:最多就是回傳一些必要的值。 05/28 07:52
→ tkdmaf:然後僅僅驗證這樣的結果符不符合條件而已。 05/28 07:52
→ tkdmaf:可UNIT TEST不是讓你毫無目的的卯起來什麼東西都要測。 05/28 07:53
→ tkdmaf:而且unit test其實可以變成TDD的！經由驗證的開發。 05/28 07:55
→ TonyQ:TDD 有點太遠了，對 unit test 都不接受的人， TDD 不會有 05/28 07:58
→ TonyQ:吸引力。XD 05/28 07:58
→ guest2008:還是老話一句.請視專案規模及複雜度而定,沒必要墨守成規 05/28 08:57
→ guest2008:以前曾搞過一個很複雜的遞迴演算法.類似那個沒auto test 05/28 08:59
→ guest2008:真的會死人.永遠不知道在哪個環節出錯.現在的都是網頁, 05/28 09:01
→ guest2008:資料庫..等等都很單純化.真的程式寫好就已經測試完畢了. 05/28 09:02
→ guest2008:而且現在都是物件導向寫法..不需要在寫啥功能.真的都是 05/28 09:04
→ guest2008:在寫檢核而已.功能在上層class早都身經百戰驗證沒問題了 05/28 09:06
推 guest2008:大家環境都不同.一定會雞同鴨講.寫一大堆 assert() 我也 05/28 09:10
→ guest2008:搞過..到現在我還是有保留少許這些東西.但幾乎真的絕跡 05/28 09:14
→ guest2008:需要動用assert的機會真的沒那麼多了.搞演算法的環境,我 05/28 09:15
→ guest2008:真的承認且有必要性寫 test case.因為連我都有寫. 05/28 09:17
推 guest2008:我想起一個笑話:很久前歐美跟日本購買燈泡.跟廠商講故障 05/28 09:24
→ guest2008:率要2%.當時日本人搞不懂歐美幹嘛要2%的故障品..於是 05/28 09:25
→ guest2008:出貨時每箱都塞2個壞的燈泡在裏面.並且註記這兩個是壞的 05/28 09:25
→ lgd1008:樓樓上的講法有點怪怪的,unit-test單純用於驗證,還可以TDD 05/28 11:11
→ lgd1008:但TDD本身不就是unit-test驗證功能的反証嗎? XD 05/28 11:11
→ lgd1008:你先寫一些test case,再製做一些mock object讓test case都 05/28 11:11
→ lgd1008:能夠通過, 這樣代表程式被驗證完了?可是程式都還沒開始寫. 05/28 11:12
→ lgd1008:unit-test的驗証功能, 應該恰好是在TDD以外的情況發揮吧? 05/28 11:13
→ TonyQ:TDD 驗證的是「界面」，而 TDD 的過程是從「不過變成過」。 05/28 11:40
→ TonyQ:不過 TDD 解釋起來有點太複雜，我基本上也還感覺不到他的好 05/28 11:40
→ TonyQ:處，所以我就不多說。XD 05/28 11:40
推 TonyQ:TDD 不是「程式還沒開始寫」的狀況，至少介面跟函式定義會先 05/28 11:41
→ TonyQ:寫，只是實作是寫完之後在做這樣。 05/28 11:41
→ lgd1008:當太多層樓的時侯,"樓樓上"是簡化的說法,仍謝謝樓上的回覆 05/28 12:08
推 tkdmaf:TDD的意思簡單來說就是：測試寫完功能也同時寫完了。 05/28 14:40
→ tkdmaf:所謂的測試驅動開發TEST DRIVEN DEVELOP 05/28 14:41
→ tkdmaf:簡單來說！你要測試資料庫連線過不過。 05/28 14:41
→ tkdmaf:一開始一定是給FALSE，因為你都還沒連嘛！ 05/28 14:41
→ tkdmaf:然後測試語法，輸入帳號密碼。 05/28 14:41
→ tkdmaf:因為連線成功就會獲得回傳值為true。 05/28 14:42
→ tkdmaf:當你驗證完這個true時，你還需要寫功能嗎？你都寫好了。 05/28 14:42
→ tkdmaf:同樣的。登入帳號密碼也是一開始給FALSE。 05/28 14:43
→ tkdmaf:用第三方測試載入功能函式給予測試值看結果。 05/28 14:43
→ tkdmaf:當結果為PASSED時，你還需要寫登入嗎？你都寫好了。 05/28 14:44
→ tkdmaf:然而因為功能開發的過程全部都有一個測試做為輔助驗證。 05/28 14:45
→ tkdmaf:萬一有BUG時，也僅需要列出驗證狀況就知道錯誤在那了。 05/28 14:45
→ tkdmaf:換個方式來說，你卯起來寫功能難道都是腦內補完程式碼？ 05/28 14:46
→ tkdmaf:寫完他就一定過？一定是修修改改修修改改...... 05/28 14:46
→ tkdmaf:那花這些時間修修改改為什麼不一開始就測試？ 05/28 14:46
→ tkdmaf:很多人都以為寫程式去測試主功能是浪費時間的一件事。 05/28 14:47
→ tkdmaf:卻沒注意到自己浪費更多時間在那想程式寫的對不對。 05/28 14:47
→ lgd1008:樓上兩位對於TDD的解釋都很怪... 05/28 17:46
→ lgd1008:如果除了在程式完成的情況, 在任一時間點, 都容許測試中有 05/28 17:47
→ lgd1008:錯誤存在.這還算是test-driven嗎? 那要怎麼分辨那些錯誤是 05/28 17:48
→ lgd1008:實作的錯誤? 還是設計的錯誤? 還是就咬定設計一定是對的? 05/28 17:49
→ tkdmaf:TDD我是基於單元測試的開發。一次僅對單一功能進行測試。 05/28 20:47
→ tkdmaf:一個函式大概就沒幾行程式碼，我想根本上沒什麼問題。 05/28 20:48
→ tkdmaf:除非你是想把一大堆程式碼塞在函式來驗證。 05/28 20:48
→ tkdmaf:對我來說，一個函式超過10行code我就有點忍耐不住了。 05/28 20:49
→ TonyQ:@lgd1008 所以這就是我為什麼說太遠了，他說得是對得，但是 05/28 21:54
→ TonyQ:這看過實例的人很難跟上。 05/28 21:54
→ TonyQ: ^沒 05/28 21:54
→ lgd1008:我想我們是在雞同鴨講, 關於TDD的討論可以停了... 05/28 22:42
推 leicheong:的確. 有做好Assert的話某程度上可以代替Unit test... 05/29 07:53