前情提要
單元測試可以說是我這幾年投入最多學習項目，
我為什麼會這麼投入? 是因為我相信這是一個有效的開發方式，
持續的上課與練習，稍微記錄一下這些年來的反思。
想法
單元測試是我覺得不論何種程式語言(雖然我並不甚理解 FP)，最最基礎的技能，
非常值得深耕，好的單元測試本身是一種規格書(spec)與使用者案例(use case)，
你想搞 CI/CD、敏捷、DevOps、DDD，都一定要有單元測試，
甚至我認為這一切只是軟體開發的本質的多面。
我個人是相當推崇 XP (極限編程)的，雖然不知道是不是因為「每周工作 40 小時」這一條，
導致企業不愛，公司不疼、專案管理協會不推、主管不敢用，
但就我來說 XP 反而是最貼近軟體工程的具體實踐(而 Scrum 只是框架，你可以把 XP 放進去)，
也是真正能快速帶來品質的作法(簡單而務實)。
缺少的拼圖(困難的現實)
學習曲線
有寫單元測試的工程師非常非常稀少，能內化寫得好的更是稀少。
為寫而寫的單元測試不但無法帶來好處，反而弊病叢生又無法為產品帶來價值。
但是學好單元測試要多久 ? 要導入又要多久 ?
這點有些因人而異，但我敢說不是只有一兩次的內訓或 WorkShop 就可以實際上戰場。人員素質參次不齊
承上，寫測試的好處，短期內很難有立竿見影的好處，
人性就是多一事不如少一事。
更糟的是，過沒多久這些人員離職、調任、昇遷，
人走了留下了代碼，一年年過去，
就只剩一個焦油坑，一代一代傳承的業力，等待被引爆。教育體系的缺乏
在台灣能把測試說到點上的講師，我只能推 91 大，
也可能是我同溫層太厚或是見識太少，有很棒的講師或網路資源請推薦給我。
如果可以的話，我希望所有軟體的教育機構都應該介紹並深入指導這門知識，
包含大專院校與各類補教機構 。不過反過來說，91 大的課程對學生來說並不便宜，時間也相當短促資訊量大，課也很難搶。
在我的觀點，台灣整體軟體產業不能只依靠一個人，希望有更多高品質的課程能夠出現。產品生命周期短
現在的公司壽命，往往比一個人的職涯短，更不用說是內部的專案壽命，
人員也常常被調任，也導致開發人員對產品或代碼的擁有權與責任感降低，
當你對自已的產出只當作是個過客，那就不會原意用單元測試去細細打磨人各有志
並不是所有人都與我有相同的想法，我認為身為開發人員必須對自已的負責，
要有「匠人心態」所以我的基礎會建立在單元測試之上。
但有得人就只是「討口飯吃」、有得人著重「商業思維」、
有得人偏重「架構設計」、有得人在乎「市場行銷」。
退一步說，這都沒錯，但是這些開發者往往不會投入太多的精力在單元測試上(或是排序上靠後)
與未來的展望
單元測試可以幫開發人員可以用更少的資源，對代碼有更深的理解，
一切都是案例，而案例是對產品的解釋，
一但理解了案例，工程師只需要組合單元或是創造新的單元。
而代碼就會是活的工程文件，可以跨越時間傳承給下一位 RD，
你傳承的不再會是業力，而是產品品質的火炬。
一但單元測試的基本知識抓住後，
測試趨動開發與重構就會水到渠成，
這兩門技術也不容易，本質上也易學難精，很需要經驗值，
測試趨動會讓我們更接近使用者，這裡指的是代碼的使用者。
反思:也許是我們太常一人同時飾演多角才會這樣的問題，那麼 Pair Programming 是不是能解決這樣的問題)
重構會引導我們到設計模式，
當然設計(架構與軟體)又是另一個領域了，未來會多找這一些課程來上。
目前這塊我也覺得是有缺憾的，TDD 之後就是重構了。
但是我並不認為硬背重構的準則或是 Design Pattern 就是解決之道，
而是應該結合兩者有系統化的設計課程，
理想上是有一個開發案例，可以循序漸進，反覆迭代的開發，
讓學徒可以由作中學，進而掌握這兩本藝術。
我希望可以有更多課程與資源可以學習讓學生們在接觸程式的當下，就接觸測試。
如何讓初階的開發者在學習路上，就接觸到正確的單元測試的姿勢呢 ?
如果未來有一天，人人都能寫出水平之上的測試，這個產業將會進入什麼樣領域呢 ?
參考
(fin)