Re: [轉錄] 開發人員的測試悖論(The Developer Tes …

看板Soft_Job作者 (無)時間13年前 (2011/05/16 20:05), 編輯推噓10(10推 0噓 29→)
留言39則, 16人參與, 最新討論串3/8 (看更多)
※ 引述《bravomao (資訊苦力)》之銘言： : 小弟斗膽分享一下個人的經驗。 : 通常我們在開發時期多少會對自己所寫的程式進行單元測試，其實這階段的測試充其量 : 也只能測試出元件的邏輯流程是否正確，如果這階段的測試都無法通過，這個程式根本 : 就是無法提交的。 像我同事他就是這樣除錯的 寫一段程式, 編譯成功 -> 設中斷點 ->執行 -> 動態更改變數跑不同流程 -> 把分支都跑過一次 -> 繼續寫下一段小程式 看他的程式幾乎都是 0 bug... 是不是這樣的方式是最好的? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.141.45.240
→
05/16 20:32, , 1F
除錯和測試不一樣啊老兄
05/16 20:32, 1F
推
05/16 21:21, , 2F
如果寫完從此不改的話, 不然 test case 開出來保險
05/16 21:21, 2F
→
05/16 22:23, , 3F
大家覺得這樣是不是比較能達成0錯誤 :D
05/16 22:23, 3F
推
05/16 22:27, , 4F
那refactoring 時，是不是要全重追一次啊...
05/16 22:27, 4F
→
05/16 22:38, , 5F
這麼累的作法，程式員是會得媽媽手的。
05/16 22:38, 5F
推
05/16 22:58, , 6F
寫test case豈不更好
05/16 22:58, 6F
推
05/16 23:38, , 7F
就算這樣除錯，如果是 multi-threading/processing...
05/16 23:38, 7F
推
05/16 23:57, , 8F
這樣做, 適合在切的很乾淨的功能模組上.
05/16 23:57, 8F
推
05/16 23:57, , 9F
這種除錯/測試方法真的是值得鼓勵的，不過真的會累死人，
05/16 23:57, 9F
推
05/16 23:58, , 10F
累死人啦，好好把程碼想清楚不就好了
05/16 23:58, 10F
→
05/16 23:58, , 11F
我的做法是不斷地重複使用自己的舊 code...當然舊 code 在
05/16 23:58, 11F
→
05/16 23:59, , 12F
操到穩定之前的那些專案...就是白老鼠啦 XD 好孩子不要學喔
05/16 23:59, 12F
→
05/17 00:33, , 13F
我想問問, 如果測試的資料是來自db(常變動)有什麼好方法
05/17 00:33, 13F
→
05/17 00:33, , 14F
讓這些unit test 不太容易隨時間而失效呢?
05/17 00:33, 14F
→
05/17 00:33, , 15F
mock object的方式很麻煩, 因為要產生一筆測資的時間
05/17 00:33, 15F
→
05/17 00:34, , 16F
可能就比寫整個enhance還久 (資料複雜,db複雜又龐大又常變)
05/17 00:34, 16F
→
05/17 00:40, , 17F
這個需求真正問題是「db複雜又龐大又常變」 這個...
05/17 00:40, 17F
→
05/17 00:44, , 18F
對阿, 但也不能看著寫出來的unit test 老是作廢...
05/17 00:44, 18F
推
05/17 00:46, , 19F
單元測試的過程每位設計師的習慣都不同，但從團隊運作的
05/17 00:46, 19F
→
05/17 00:46, , 20F
作的角度來看，您的元件的輸出入規範反而是最要求的部份
05/17 00:46, 20F
→
05/17 00:48, , 21F
_則也不是太多人有興趣慢慢的研究，但是你設計的元件輸出
05/17 00:48, 21F
→
05/17 00:48, , 22F
入規格沒有定義清楚，那....會搞死一堆人!
05/17 00:48, 22F
→
05/17 00:49, , 23F
再者我覺得交易流程的設計與處理也是設計上的一個大課題
05/17 00:49, 23F
→
05/17 00:49, , 24F
我曾遇過一些系統明明就適合以非同步的方式來設計，但是
05/17 00:49, 24F
→
05/17 00:49, , 25F
不知怎麼著就是用了同步的處理方式來設計，當交易過程有
05/17 00:49, 25F
→
05/17 00:50, , 26F
一些非即時回應的外部系統參雜在裡面的時候....也變成災
05/17 00:50, 26F
→
05/17 00:50, , 27F
難。這樣的東西在單元測試的時候都很容易被忽略，各寫各
05/17 00:50, 27F
→
05/17 00:51, , 28F
的，都沒問題，但是一旦整合測試一來.....很慘!
05/17 00:51, 28F
→
05/17 00:51, , 29F
其實我覺得很多痛苦是在整合測試的時候發生的，舉例來說
05/17 00:51, 29F
→
05/17 00:51, , 30F
JVM本身的運作方式從程式學習的路徑來看很不被重視，許多
05/17 00:51, 30F
→
05/17 00:52, , 31F
JAVA的觀念像是Java的Monitor或者是Thread Pool之類的東
05/17 00:52, 31F
→
05/17 00:52, , 32F
西的使用以及管理都是有很多的問題，小弟以前剛學的時候
05/17 00:52, 32F
→
05/17 00:52, , 33F
也是先求有、再求好，但專案時程在這一來一往之間就越來
05/17 00:52, 33F
→
05/17 00:52, , 34F
越緊迫，導致先求有，也沒時間求好.....
05/17 00:52, 34F
推
05/17 01:02, , 35F
不會說他做錯, 但測試不是就這樣子而已
05/17 01:02, 35F
推
05/17 22:53, , 36F
writing solid code這本書有說原Po這個方法, 我自己也
05/17 22:53, 36F
→
05/17 22:54, , 37F
是這樣做.
05/17 22:54, 37F
→
05/18 02:01, , 38F
這方法並不誇張阿, solid code 裡面也有講到..
05/18 02:01, 38F
→
05/18 02:02, , 39F
我面對複雜的演算法的時候也會這樣做 @@~
05/18 02:02, 39F
‣ 更多 Ting1024 的文章
文章代碼(AID): #1DqHC0Dr (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 3 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 Ting1024 的文章
文章代碼(AID): #1DqHC0Dr (Soft_Job)