→ dryman:除錯和測試不一樣啊老兄 05/16 20:32
推 ledia:如果寫完從此不改的話, 不然 test case 開出來保險 05/16 21:21
→ Ting1024:大家覺得這樣是不是比較能達成0錯誤 :D 05/16 22:23
推 HYL:那refactoring 時，是不是要全重追一次啊... 05/16 22:27
→ qrtt1:這麼累的作法，程式員是會得媽媽手的。 05/16 22:38
推 chchwy:寫test case豈不更好 05/16 22:58
推 plover:就算這樣除錯，如果是 multi-threading/processing... 05/16 23:38
推 ericinttu:這樣做, 適合在切的很乾淨的功能模組上. 05/16 23:57
推 ppaass:這種除錯/測試方法真的是值得鼓勵的，不過真的會累死人， 05/16 23:57
推 guest0079:累死人啦，好好把程碼想清楚不就好了 05/16 23:58
→ ppaass:我的做法是不斷地重複使用自己的舊 code...當然舊 code 在 05/16 23:58
→ ppaass:操到穩定之前的那些專案...就是白老鼠啦 XD 好孩子不要學喔 05/16 23:59
→ newjoy:我想問問, 如果測試的資料是來自db(常變動)有什麼好方法 05/17 00:33
→ newjoy:讓這些unit test 不太容易隨時間而失效呢? 05/17 00:33
→ newjoy:mock object的方式很麻煩, 因為要產生一筆測資的時間 05/17 00:33
→ newjoy:可能就比寫整個enhance還久 (資料複雜,db複雜又龐大又常變) 05/17 00:34
→ TonyQ:這個需求真正問題是「db複雜又龐大又常變」 這個... 05/17 00:40
→ newjoy:對阿, 但也不能看著寫出來的unit test 老是作廢... 05/17 00:44
推 bravomao:單元測試的過程每位設計師的習慣都不同，但從團隊運作的 05/17 00:46
→ bravomao:作的角度來看，您的元件的輸出入規範反而是最要求的部份 05/17 00:46
→ bravomao:_則也不是太多人有興趣慢慢的研究，但是你設計的元件輸出 05/17 00:48
→ bravomao:入規格沒有定義清楚，那....會搞死一堆人! 05/17 00:48
→ bravomao:再者我覺得交易流程的設計與處理也是設計上的一個大課題 05/17 00:49
→ bravomao:我曾遇過一些系統明明就適合以非同步的方式來設計，但是 05/17 00:49
→ bravomao:不知怎麼著就是用了同步的處理方式來設計，當交易過程有 05/17 00:49
→ bravomao:一些非即時回應的外部系統參雜在裡面的時候....也變成災 05/17 00:50
→ bravomao:難。這樣的東西在單元測試的時候都很容易被忽略，各寫各 05/17 00:50
→ bravomao:的，都沒問題，但是一旦整合測試一來.....很慘! 05/17 00:51
→ bravomao:其實我覺得很多痛苦是在整合測試的時候發生的，舉例來說 05/17 00:51
→ bravomao:JVM本身的運作方式從程式學習的路徑來看很不被重視，許多 05/17 00:51
→ bravomao:JAVA的觀念像是Java的Monitor或者是Thread Pool之類的東 05/17 00:52
→ bravomao:西的使用以及管理都是有很多的問題，小弟以前剛學的時候 05/17 00:52
→ bravomao:也是先求有、再求好，但專案時程在這一來一往之間就越來 05/17 00:52
→ bravomao:越緊迫，導致先求有，也沒時間求好..... 05/17 00:52
推 hinaeddie:不會說他做錯, 但測試不是就這樣子而已 05/17 01:02
推 ctrlbreak:writing solid code這本書有說原Po這個方法, 我自己也 05/17 22:53
→ ctrlbreak:是這樣做. 05/17 22:54
→ yoco315:這方法並不誇張阿, solid code 裡面也有講到.. 05/18 02:01
→ yoco315:我面對複雜的演算法的時候也會這樣做 @@~ 05/18 02:02