Re: [討論] 工作上寫單元測試的比例

看板Soft_Job (軟體人)作者pichubaby (Pichu Chen)時間6月前 (2024/05/05 12:17)推噓3(3推 0噓 6→)

留言9則, 4人參與討論串9/10 (看更多)

※ 引述《chopinmozart (aha)》之銘言： : 想請問一下 : 大家工作上寫單元測試的情況 : 1.大部分寫完一個功能, 就馬上完成單元測試 : 2.先把該做的功能寫完, 再回來統一寫單元測試 : 3.不怎麼寫單元測試 : 想請問大家工作實際情況大概是哪一種QQ 原則上要寫測試的話我會用很古老的 TDD 的方式做，先寫測試之後再寫實作。現在的話則是寫完測試之後 Copilot 就幫我寫完一半了，然後就開始 review copilot 的 code 了。目前經驗上能不能寫測試的話我認為有三個維度會是主要影響關鍵，提供參考： 1. 文件是否齊全 2. 設計是否經常變動 3. 該功能會被是否不容易被其他方式偵測錯誤文件是否齊全應該是主要的關鍵，如果前面沒有文件的話搞不好測試本身就是錯的了。齊全的文件像是 json.org 的 json 格式不齊全的像是 PM 要求要有使用者登入功能，但是沒有說清楚是 username, email 或是電話號碼，電話號碼可不可以有加號，密碼有沒有長度限制。設計是否經常變動也是重要的主要關鍵，因為變動就有可能增加意外(人為失誤) 像是財政部電子發票交換格式可能幾年變動一次文件又明確的話就可以寫測試如果說是一次下要求密碼8碼然後下個 Sprint 又變成 12 碼，然後再下個 Sprint 又說十碼就夠了，這時候測試就容易出包，或者是要思考是不是修改架構，讓使用者密碼長度可以自由設定，驗證條件多加入讓管理者自訂密碼長度這樣。再來是否會被其他方式偵測錯誤我認為是現況下很多程式不做測試也可以用的原因因為使用者會幫忙做測試，所以造成某些容易發生的問題自然就容易被發現找到，同時如果該問題損害低的話，那麼就期望值而言也許損失期望值會大於寫測試的成本。舉例來說，如果是比較少出現的設計，例如錯誤處理，就會比較建議測試，因為後面的 QA 漏測的機率比較大，如果是比較多人常用的部分，例如正常登入，再後續測試通常能抓到，在寫測試的優先順序可能就會往後。我想這應該是 pttbbs 的程式碼基本上都沒測試但是還是活得好好的原因吧? --- 另外流程是否文件化或是測試程式碼的數量有的時候其實是管理層責任，畢竟大腦判斷某項細節不重要就有可能忘記，所以以前某段程式碼怎麼寫的即使是作者本人也有可能不記得，更不用說人員流動離職交接的狀況了。大量沒有測試(或是文件)的程式碼造成的問題基本上就是程式碼變動的成本會隨系統架構呈現指數上升。本來要在五行裡面來回測試哪一行有問題，變成在一百行裡面找出哪一行有問題。 -- 人紅是非多，活益比非多。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 150.117.165.81 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1714882664.A.026.html