前兩篇文章，我們先以當下物件的角度，思考屬於自己的職責是什麼。而不屬於自己職責的部份，該委託給哪個物件來進行。並思考清楚當下物件所需要的，究竟是什麼，接著不必去管相依的物件如何實作，儘管開口叫他做，再跟他要結果即可。
接著，要怎麼確保其他物件的執行結果是我們要的呢？就是建立測試案例，先行建立單元測試。在其他物件的行為中，都還沒有實際的內容時，在我們動手撰寫其內容前，我們已經都思考好，這些物件接受到什麼資訊，該回傳怎麼樣的結果。有了這樣的前提，才能確保我們設計相依物件時，目的就是為了滿足當下物件的需求，目的就是為了通過測試案例。
而相依物件的測試案例怎麼產生呢？因為我們是先撰寫更上層的整合測試（在這例子是Selenium），在整合測試的input中，有一些脈絡可循，可以找到對應相依物件的input值，以及預期的output值。當下物件是頁面，只負責蒐集資訊，呼叫其他物件，呈現結果。
到這，已經是萬事具備，只欠東風。欠什麼東風？就是想辦法通過測試。因為這一系列是重構，所以我們根本不需要額外撰寫太多的程式碼（甚至只需要挪動程式碼），只需要把原本的程式碼，一個蘿蔔一個坑的，擺到它應該放的位置上，接著按個鍵就可以確認這樣的搬移動作是否有錯。
搬code，按下執行測試，我可以肯定你3分鐘就學會了！![讚]()
上一篇文章：[Day 14]Refactoring - 驗貨
本系列文章專區
接著，要怎麼確保其他物件的執行結果是我們要的呢？就是建立測試案例，先行建立單元測試。在其他物件的行為中，都還沒有實際的內容時，在我們動手撰寫其內容前，我們已經都思考好，這些物件接受到什麼資訊，該回傳怎麼樣的結果。有了這樣的前提，才能確保我們設計相依物件時，目的就是為了滿足當下物件的需求，目的就是為了通過測試案例。
而相依物件的測試案例怎麼產生呢？因為我們是先撰寫更上層的整合測試（在這例子是Selenium），在整合測試的input中，有一些脈絡可循，可以找到對應相依物件的input值，以及預期的output值。當下物件是頁面，只負責蒐集資訊，呼叫其他物件，呈現結果。
到這，已經是萬事具備，只欠東風。欠什麼東風？就是想辦法通過測試。因為這一系列是重構，所以我們根本不需要額外撰寫太多的程式碼（甚至只需要挪動程式碼），只需要把原本的程式碼，一個蘿蔔一個坑的，擺到它應該放的位置上，接著按個鍵就可以確認這樣的搬移動作是否有錯。
搬code，按下執行測試，我可以肯定你3分鐘就學會了！
上一篇文章：[Day 14]Refactoring - 驗貨
本系列文章專區