※ 引述《H45 (!H45)》之銘言： : ※ 引述《PsMonkey (痞子軍團團長)》之銘言： : : 簡單地說，傳統結構式的語言，像 C 的 function : : 你還是可以套用 Unit Test 的觀念吧？ : : ^^^^ : : 又沒說一定要... cccc : : ㄜ... 我書念得不多 : : 可以講一下，如果 unit testing 納入考量 : : 會在 OOAD 的階段產生什麼影響嗎？ : : 如果有考慮跟沒考慮，OOAD 的過程跟結果會差很多 : : 那或許在這裡提 unit testing，有其必要 : : （但是剛開版就來這個... 也許... [逃]） : 因為 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 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 202.22.246.26 ※ 編輯: adrianshum 來自: 202.22.246.26 (07/20 14:16)