啟稟軍師，東風來了

等了好久，終於等到東風了，我們可以開始慢慢的推導了。

如何處理 Build fail

如果是 Build fail ，通常就是少上傳東西，導致建構失敗， CI 會在有人受害前就幫我們發現這個問題。這個通常是 Coding 的習慣還沒養成。

此時你可以上前告訴他，剛剛上傳的東西好像有點問題，跟他一起找一下問題，並宣揚一下這是 CI 幫助我們發現的，讓大家知道原來你搞了一台 CI 還是有一點點作用。

如何處理 Test fail

如果是 Test fail ，請你拿著測試情境去跟夥伴討論一下，跟他說他剛剛修改的東西好像在這樣的測試情境下會有問題，並且有耐心的跟他一起解決問題。

最好順便多加幾個測試情境。同時宣揚一下 CI 會在我們 Commit code 時幫我們跑測試，會幫我們確保我們的程式碼執行是正確的。

當然，正確使用單元測試的時機，是修改程式的時候就應該要馬上跑單元測試。不過對還沒養成跑測試習慣的人來說， CI 幫我們在交付程式碼時，給了我們一層保護。

讓大家感受到自動化測試的好處

當這樣的情況多發生幾次後，團隊成員就會感受到 CI 和自動化測試所帶來的好處，而且你們交付出去的東西被發現 Bug 的次數就會變少。

想必此時已經有不少的團隊成員對寫測試有興趣了，接下來就把你之前怎麼慢慢學習的，跟他們再一起走一次吧。我相信會比一開始就強迫大家寫來的順利多了。

接下來所面對的問題

這時你可能會遇到另一個問題，不是每個人都會想用另外的 20 小時來學習的，就算他們用了那 20 小時來學習寫測試，也會面臨另一個問題，為什麼我要花自己的時間在幫工作上的程式寫測試。最後大家會想把測試台面化，也就是用上班時間光明正大的寫測試。

然而測試台面化第一個所要面臨的問題就是 PO/PM，他們會覺得你們所開發的東西變少或變慢了。

今天請你先想一想面對這個問題我們該怎麼辦，明天我們再來討問一下。