※ 引述《adrianshum (Alien)》之銘言： : ※ 引述《H45 (!H45)》之銘言： : : 因為 OOAD 的上一層是軟體工程 : : 所以系統在開發的過程中勢必少不了一些前提 : : 現在就假設以 test-driven 的方法來開發軟體 : : 開發程式之初，最需要的就是「需求的擷取」 : : 再度假設現在已經知道了系統的需求與功能 : : 那麼緊接著就是做一連串的 test case : : 做完了 test case 之後就是真的去發展系統本身 : : 但是系統發展的過程中，不是每次都能夠像 waterfall 一樣從頭就做到尾的 : : 而是會有數次的 iteration, 進行循序式的發展 : : 也許哪天系統需求有了變化，也許設計上有些元件不夠具有彈性 : : 或者某些類別的命名不太理想，又或許突然發現套用一個 design pattern 會更好 : : 那麼這個時候當初訂下來的 test case 是否也需要做一些調整呢？ : : 答案很明顯是肯定的。 : : 這個時候如果又剛好是 Object oriented language : : 那麼就會出現另一個問題：test case 要怎麼設計會比較具有彈性？ : : 一般而言，test case 必須對介面進行呼叫，而非針對葉類別進行呼叫 : : 因為葉類別在系統發展中處於一個不穩定的狀態，而介面卻往往是最穩定的 : : 所以 test case 就會傾向於呼叫介面的操作。 : : 但是呼叫介面的操作之前又必須先產生實體才有辦法真的做測試 : : 要解決產生實體的問題又可以使用 factory pattern 來設計 : : 整個就變得和 OOAD 十分的有關係了 : 這部份不太贊同 : 沒錯, 做 unit test 時通常會比較針對 : interface 提供的東西來作測試, 但test case : 本身是用來測試特定的 implementation 的. : 換而言知, 對 test case 而言, 它是知道它 : 要測試的是哪一個 implementation, 產生實 : 體該由 test case 自己做就好, 如非必要, : 不必另外藉由 factory 去 instantiate. : 而 unit test 的理念該是盡量只碰你要測試的 : class 就好, 如果還去找個 factory 來生產你 : 要的 impl 的話, 涉及與 test 不相關的東西就變多, : test case 的準確程度反而變低. : : 不知道這樣的回答有沒有解釋到.... : : 雖然我還是比較贊同 unit testing 和 OO 沒有直接的關係 : : 但是還是試圖說明了一下 unit testing 要怎麼和 OO 扯上關係 : Alien 感謝您的指教 敝人不才 這邊有另外一個問題想請教： 'object oriented and component-based software development' 是否為 'use case-driven software development'? 因為這個連結提到： "Anyone who works on object oriented and component-based software development projects needs to understand use cases and the role they play in use case-driven software projects." Link: http://www.parlezuml.com/tutorials/usecases.htm 在 Head First OOA&D 這本書中 (O'Really) 提到多種 Oo 發展方法 好比說：use case-driven, feature-driven, test-driven development 這麼多種方法，看起來沒有規定 Oo 一定要用哪一種開發方式 但是它最後決定使用 feature-driven development 是吧？ 看起來 use case 好像是一切的源頭，寫完之後再做出需求功能的清單 最後再根據需求功能的清單進行分析和設計 所以我大膽斷定，必須先有 use case, 這樣才有辦法進行 Oo 分析與設計 不知道這樣的見解有沒有錯誤呢？ 不管如何，unit testing 和 test-driven development 都和 OO 無關 這點應該是沒問題.... -- 如有謬誤就不用客氣了.... --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.211.211.53 ※ 編輯: H45 來自: 218.211.211.53 (07/21 00:00)