1、測試的使用場景
適合大團隊多人協作開發，項目開發過程中每個程序員看不到且得不到其他人的代碼（每個人都是單獨開發自己的代碼片段），代碼開發完成后再集成到一起進行調試等操作。這個環境下，你寫的代碼只是一個代碼片段，不寫測試的話，你都不知道你的代碼能否正常運行，能否得到正確的結果。然后就是代碼邏輯特復雜，方便開發完成后修改調試，可以寫寫測試。還有就是你寫的某個功能、工具什么的需要測試一下，就像是那些開源項目（框架/庫什么的）。
2、國內多數開發場景下，測試的好處
國內很少有測試的使用土壤，大多都能拿到整個項目的代碼，你跑跑項目就知道行不行了。如果使用了，他的好處是：一個是強迫開發者寫出比較規范的代碼，另一個是在新功能開發完成后（新功能開發時，測試的邏輯和開發的邏輯是一樣的，能測試出來都是有鬼了）且需求不變（業務、架構、邏輯等不調整）有用（比如：胡亂修改一通，發現測試有問題且能看到是哪兒有問題）。當然了，你寫的代碼邏輯特復雜，也可以寫寫測試，防止以后手賤改了哪兒不好調試，這個也會陷入上文提到的問題。所以，總的來說，測試是比較雞肋的。況且想想國內的環境，加班加點，哪有那么多時間搞。
3、個人建議
想要完善自己的技術棧可以玩玩，閑著沒事可以搞搞。寫測試是為了證明你的代碼是正確的，能想到的測試點開發時會避免相關問題，想不到的呢（交給測試專職人員）？
