練習過程

TDD 是一種開發方法，因此我們嘗試在學習 Laravel 的過程中、一邊實踐著 TDD，去完成我們的留言板練習。

在這次的練習中我們學習了：

1. Larvel 的基礎使用，包含
   • 路由
   • 樣板
   • 資料庫
   • 會員驗證
2. 利用 PHPUnit 測試 Laravel
3. 利用 Laravel Dusk 測試 UI

原本預計還要進入 API 的練習，實際上當前、後端的任務獨立出來時，後端工程師很多比例是專注在 API 的撰寫上。

然而有點可惜受限於時間不夠，因此對於 Laravel 的 TDD 練習文章就到這邊為止。

心得

過程中曾經體會到 TDD 帶來的好處，在這個系列的第三天時 TDD 的理由 整理過 TDD 會帶來的好處，在實際練習過後回來檢視一次那幾點：

1. 促使開發者思考結構
   - 寫出可重複測試的程式
   - 減少程式之間的耦合
   - 函式小而簡潔

我們在 TDD 過程中完成了多個自動化測試，當然重複執行。

我們也的確會因為要先寫測試，而提前思考程式架構。

但提到程式的耦合性與簡潔的函式，似乎還沒辦法判斷，無法否認有一定比例是借助了 Laravel 的完整架構。而且我們的測試函式，多數都寫得蠻長的，重複的程式碼也不少。

2. 易於重構 (Refactor)
3. 減少 Debug 的時間

我們的確有借助到這兩個好處，修改程式時，透過保持測試通過，來確保我們的測試並沒有被破壞。

當有破壞掉時，自動化測試很快地就告訴了我們，並且是在哪一個測試發現錯誤，也就會指到是哪一個功能被破壞了。

除了在語法上花了一點時間學習以外，實際 Debug 的時間我主觀判斷覺得有減少。

4. 高測試覆蓋率

這個部分並沒有在 Laravel 段落文章中介紹過，但我自己曾經有試著產出過 PHPUnit 的覆蓋率報告。

但結果是，並沒有在這次練習中帶來高覆蓋率，原因是，程式碼中包含著大量 Laravel 原本就寫好的部分在其中，而我們認為那些並不需要被測試，但 PHPUnit 依然會計算它們的覆蓋率。

難處

TDD 的確不容易實踐，這是在這次練習過程中也實際體會到的。

而為什麼會感到困難呢，在系列第十天 如何在一個環境開始 TDD 時有提過其中一些。

Laravel 絕對可以做自動化測試，因此最重要的，就是對工具不夠熟悉，包含了 Laravel 與測試相關的語法跟函式。

再來就是，因為還不擅長寫測試，每個測試幾乎都又長又難讀 (如果真的有讀者看完那些 Laravel 的程式碼的話)，函式之間或測試之間的耦合性，使得維護性差。

改進

關於如何改進，簡單就能歸納到顯而易見的這幾點：

1. 熟悉語法與工具
2. 練習
3. 閱讀

以下幾本書還在我的清單中排隊：

1. 單元測試的藝術
2. CODE COMPLETE：軟體開發實務指南
3. 重構─改善既有程式的設計

也許都會跟這個議題有關，讓我們一起持續學習吧。