※ 引述《PsMonkey (痞子軍團團長)》之銘言： : ※ 引述《H45 (!H45)》之銘言： : 簡單地說，傳統結構式的語言，像 C 的 function : 你還是可以套用 Unit Test 的觀念吧？ : : 不得不承認真的不 OO 了 : : 雖然物件導向的分析和設計中 : : 如果採用 test-driven development 的話 : ^^^^ : 又沒說一定要... cccc : : Unit testing 會是很重要的一環 : : 在分析的時候，不只是把 unit testing 納入考慮，也一併加入了系統的架構 : : 整個系統的發展將會與 unit testing 習習相關。 : ㄜ... 我書念得不多 : 可以講一下，如果 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 testing 和 OO 沒有直接的關係 但是還是試圖說明了一下 unit testing 要怎麼和 OO 扯上關係 -- 如有謬誤，仍然請不吝指正 --

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