最近在某些機緣下，有機會可以將自動化單元測試導入我們團隊，
由於我們團隊對於單元測試較無經驗，
在引入的過程中，應該會遭遇一些問題，
所以我想將這段引入的過程跟我的想法記錄下來，以供日後檢討與反思。
構想
說到自動化測試，以後端開發者來說，最基本的應該是單元測試。
我找了一些書來看，像是「單元測試的藝術」、「Test-Driven Development: By Example」等著名的作品，並且大量搜尋了網路上了文章。
我發現最大的問題在於，單元測試已經發展成一個專業的技能，有很多「術語」（mock、stub、SUT、⋯⋯），和流程，例如TDD，
那為什麼這些是個問題？因為對於普通程度的工程師來說，要學習這些術語跟流程，其實是有困難的，而且平常就有專案的時程壓力，很難騰出時間去另外學習。
而且根本就沒有寫過單元測試，也不懂這些術語、工具、框架、流程，到底為什麼而存在。
還沒看懂這些術語跟流程，就被趕回去做專案了，怎麼可能開始寫測試？
再加上既有程式都還沒有補上單元測試，所以如果真正撰寫完整的單元化測試，可能要面臨的相依性問題，需要大量重構，又是一項極大的阻力。
況且我也沒辦法跟老闆說，讓我們整個開發團隊要停止開發新功能一整個月，只學習單元測試，然後重構程式跟撰寫自動測試，我應該會被趕回家吧。
所以我覺得，先不要管這些困難的術語和流程，我想讓團隊先培養撰寫測試的習慣。
或許透過code review或其他方式，漸漸要求大家寫少量的測試，然後定期檢討做法，等大家漸漸地習慣寫測試後，再來訂立相關的規範。
屆時再來引入比較現代化的觀念，並開始進行大規模重構，會是比較可行的做法。
行動
基礎建設與流程
為了讓大家可以開始寫測試，我先幫大家在開發環境裝好phpunit（我們使用php+laravel，並用git作版控)。
並且在gitlab上設定好runner，這個runner的作用是每次commit時並且push到repository時，都會自動執行phpunit跑測試。
因為測試是否通過，都可以在gitlab介面上看到，這個用意是讓大家知道，測試的結果，是會被看到的，希望可以藉此引起大家的注重。
但這個階段，即便測試沒有通過，我們還是會讓這個commit自動deploy出去。為什麼？
其實一來是，我們原本的團隊開發品質本來就還可以了，也會經過一定的review，不至於把糞code送出來，就算有錯也不會是大錯，
二來則是，如果測試failed就不過，那對於目前還不擅長寫測試的同事，會花太多時間在測試上，這不是我的本意。
開始寫測試
另外如同前面提到的，大家都沒有足夠的單元測試經驗。因此我必須負責去學習及研究，並且負責把相關知識傳授給其他同事，降低其他人的學習阻力。
我預計會花一到兩個月甚至三個月的時間，在盡量不影響原專案進行的情況下，建立完整流程。
第一個月讓大家熟悉，希望第二個月後可以開始建立完整流程與規範。
同事要做的事情就是開始寫測試，即便寫得跟差也沒關係，反正開始寫就對了。
而我要做的事情大概就是寫一些測試案例的範例，並且告訴同事們如何做，還有為什麼這樣做。做code review的時候，也要要求他們補上test case，並且針對大家所寫的測試案例做討論。
每週或隔週要找大家開會，檢討測試的進行方式，藉此達成共識並建立規範，或是看時機是否成熟，開始引入進階的概念。
最後
呼應一下標題，我覺得第一步就是：
培養撰寫測試的習慣
只有開始寫測試後，降低學習曲線，後續的改進才不會是空談。
現在同事們已經要開始寫測試了，我也要開始進行前面所提及的事情，希望事情會跟我預想的一樣順利（大概不可能）。
最後反思一下，其實想要引入任何新概念或新觀念進入團隊其實都是有難度的，除非整個團隊都是非常高效且願意花時間自我學習的。只是這樣的團隊可遇不可求的，還是要務實一點去想實際可行的方法。
而且自己寫單元測試，跟整個團隊都要遵照一樣的規則寫單元測試，其實是不一樣的事情，要考慮的事情很多，在沒有相關經驗的情況下，或許一步一步來才是對的。（老闆什麼時候要hire有經驗的人進來？）