引述《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 OOAD只是開發流程中設計部分的一種方式.. 但開發流程等不等於軟體工程, 應該是見人見智的問題.. 舉凡 雛型式開發 瀑布式開發 到 漸進式及 ExtremeProgramming (英文不好, 前三個英文不會打, 請多包涵. XD) 哪一種是不包含 測試 這個部份的? 而且雛型 及 瀑布式開發等等 一些開發流程, 從尚未有OO的時代就已經發展出來了.. 所以話說回來. Unit Testing 嚴格說起來不只是針對 OO而已.. 應該說它是 測試 理論中的一部分. 均適用於 物件導向及結構式程式設計.. 所以那些發展出這套理論的人也都鼓勵程式設計師遵循這些方法去測試.. 而非指特定的OOP, 目前比較常見的Junit 等等的測試工具. 是有人以特定的程式導向去實作出測試理論. 以便讓某程式導向的Programmer 方便使用. 如此而已. 其實剛開始學的人, 很容易把某些工具跟理論或標準規格劃上等號. 就像以前小弟小時候不懂事, 把FrontPage當作 Html一樣. Unit Testing 歸 Unit Testing, OOAD歸OOAD 一個是測試. 一個是設計.. 要說有關係, 也不過是用 Unit Testing 去試你設計出來的東西對不對而已吧? --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.160.124.20