上週課程回顧
詳細的上週課程心得可以參考「自動測試與 TDD 實務開發（使用 C#） by 91 哥 Day1」。
上週課程提到，什麼是 Unit Test ，好的單元測試需要吻合 F.I.R.S.T 原則，如何針對單一功能撰寫單元測試，了解開發流程與方式，了解業務單位需求撰寫需求文件與單元測試，針對單元程式建構出來的程式架構完成 Production Code 相關邏輯。
有了單元測試，就算需求來了想要調整 Production Code 都不用怕，因為有了單元測試，單元測試會告訴開發者，程式是否還是可以正常的運作（綠燈），如果為紅燈就知道有功能被改壞了，可以「即時」發現問題並且進行修正。
透過 Code Coverage 可以了解我們的單元測試的完整度，是否有遺漏的測試案例。
本週課前提要
上週學習了 Unit Test 但可能還是無法直接套用到正在進行中的專案，因為專案上可能都是滿滿的 Legacy Code ，無法針對 Legacy Code 進行測試，需求不斷的來招架不住該怎麼辦？我想今天的課程就是重點了，透過 E2E Testing 、 Unit Test 與 Refactor 來教你，「如何安安心心 Refactor Legacy Code 還可以完成業務單位新需求」。
該還的技術債還是要還，如果只是在 Legacy Code 上疊床架屋， Code 只會越來越亂， Bug 只會越來越多，只會讓後面維護的工程師越來越不懂這個系統的原貌，趁早治療才是明智之舉，千萬不要放棄治療。
本週課程前的小故事
老闆：「Hash，今天有個客戶跟我說他想要在我們的購物車上面加上可以自動進行折扣的功能，明天可以完成嗎？」
Hash：「痾…. (Hash的內心話：雖說只是加幾行 Code 就可以搞定，但… 會不會改壞其他東西阿)」
老闆：「怎樣？」
Hash（心虛的說）：「好…」
本週課程重點
- TDD
- End-To-End Testing
- Refactor
End-To-End Testing
課程中透過 Selenium 來指導學員如何透過他來對網頁進行 E2E Testing ， Selenum 除了可以直接針對網站進行測試外還可以匯出 C# 測試原始碼直接無痛整合進行 Visual Studio ，讓 E2E Testing 與 UnitTest 一起來，進而達到完整測試。
上課採雷心得分享： Firefox 的 Selenium 再 Firefox v46.1 之後的版本有 Bug 。
Refactor
終於來到本週最為精采的「如何針對 Legacy Code 進行 Refactor」，結合網頁測試與單元測試來達成我們的目的 Refactor 。
當我們有了 E2E Testing 可以針對特定功能撰寫網頁測試案例，以使用者為出發點操作系統功能，記錄使用者的行為與預期結果。
當我們有了單元測試，針對最小的功能進行測試，預期這些功能方法的行為與其回傳值。
有了他們，修改程式後馬上進行完整 Unit Test 修改程式碼的方法後是否還吻合我們的測試案例預期行為，若為綠燈，則接著進行 E2E Testing 測試是否使用者還可以如預期的操作系統功能，修改程式碼超安心，一點都不擔心會不會改壞程式碼，還有什麼比這個還要更棒的呢？
91 哥補充：重構過程中千萬不可增加新功能，一次只做一件事情，重構完成 -> 綠燈 -> 增加新功能
本週課程後的小故事
同上一樣的故事內容
老闆：「Hash，今天有個客戶跟我說他想要在我們的購物車上面加上可以自動進行折扣的功能，明天可以完成嗎？」
Hash（心理想著）：「有了 91 哥教我們的測試方法，我想花個一天把相關 Legacy Code Refactor 一下，半天完成老闆功能，沒問題！！」
Hash（有自信的說）：「好老闆，明天下午給你！」
老闆：「太好了，謝謝你的幫忙」
其實一樣的故事內容課前與課後Hash的回答的方式是完完全全不一樣的，就算今天要花時間整理 Legacy Code 而無法如期交出功能，也可以跟老闆提出需要進行程式碼重構進而提升系統穩定度，我想老闆的接受度也是高些的。
本週課程心得
就如同小故事告訴我們的，透過完整的測試流程與方法，可以讓工程師們在修改程式上更為有自信且更為安心，其實只要隨手 Refactor 一隻 Method 與補上幾隻測試程式，就可以達到讓整個專案穩定度提升。
《Clean Code》 文中提到，童子軍原則：「離開營地前，讓營地使用前更加乾淨」，同樣的原則也可以透用在軟體開發上，程式碼在 Commit 前只要可以讓 Code Coverage 提昇些，讓程式碼看起來更整齊乾淨就是進步。