我目前的專案沒都沒有測試該怎麼辦？

如果你目前的專案都沒有測試，那想必你要加測試是很困難的一件事情，因為當初再寫 code 的時候並沒有考慮要怎麼測試它。所以這邊針對要怎麼開始寫測試給以下的建議：

• 從新的專案開始
• 從新加的功能開始
• 從有 Bug 的地方開始
• 你想要改善你的設計的時候

從新的專案開始

新專案因為沒有 legacy code 的關係，寫起測試也會相對容易一點。

非常不建議新專案還是從舊專案 Copy 東西過來改，這樣 legacy code 也會一併過來，又會回到改不動的情況。如果你覺得 Copy 過來改比較快，那你可以參考一下 Day 1 開學了!來看看孩子的聯絡簿吧!。想想你會得到什麼，會失去什麼。

你可以把舊專案當成參考，例如這邊應該怎麼寫，突然想不起來，可以回去參考一下舊的專案，再從新寫的過程中你可以學到很多，可以瞭解自己還有哪些不懂的，可以知道自己在這段時間是否有什麼進步，有沒有辦法寫的比過去的好。很多都是在沒有 legacy code 的包袱下才有辦法享受的。

從新加的功能開始

如果今天我們要加一個新功能，這邊指的是一個全新的功能，跟舊的系統沒有太多的相依性，那麼就是一個好的練習寫測試的機會。

你可以單獨寫測試來測試你的新功能是否正確，執行結果是否如你所預期。如此一來你就可以確保你的新功能的正確性，而且你的新功能也有測試保護。

從有 Bug 的地方開始

當你遇到 Bug 時，第一個動作不是去修改它，而是寫測試讓這個 Bug 重現出來。

例如你有一個做加法的函數，他輸入 1+1 時輸出是 3，這時你應該先寫一個測試，這個測試就是去呼叫這個加法的函數，並且輸入是 1+1，然後預期它的輸出是2，但由於目前的輸出是3。所以測試應該是紅燈，代表失敗。

這時你再去修改你的程式，將它改對。再跑你的測試，如果你的修改是正確的，那麼測試應該就會是綠燈代表成功。

當然，這是屬於比較難的部分，因為它或多或少會跟舊的系統扯在一起。

你想要改善你的設計的時候

當你想要改善你的設計時，在開始動手改程式之前，你應該也是要先加一個測試，驗證你原本的東西是對的。

然後再動手改，如果在過程中你改錯了，那你的測試就會是紅燈，代表失敗。如果你改寫對了，你的測試就會是綠燈，代表成功，也代表你的功能跟原本的一樣，這樣你就改好了。

這個過程就叫做重構。有一個測試在那保護你重構的過程。

我該強迫其他人一起寫測試嗎？

接下來你可能會想，只有我寫好像不太對，那我應該要強迫其他人跟我一起寫測試嗎？
我們明天再來討論這個問題。