Re: [討論] 工作上寫單元測試的比例
※ 引述《chopinmozart (aha)》之銘言：
: 想請問一下
: 大家工作上寫單元測試的情況
: 1.大部分寫完一個功能, 就馬上完成單元測試
: 2.先把該做的功能寫完, 再回來統一寫單元測試
: 3.不怎麼寫單元測試
: 想請問大家工作實際情況大概是哪一種QQ
我覺得命題不是寫/不寫。
真的該問的是，工作上 reviewer 也好、或者是開發流程也好，
有沒有辦法【正常的判斷】 test 是不是寫對的。 XD
起碼是 team 能有一定認同的前提。
其實最後都回到 quality check，不然只是繞圈圈而已。 XD
這題目有興趣也可以參考很久很久以前寫的這些
3 10 3/24 TonyQ □ [閒聊] 笑談軟體測試的幾個階段（一） 測試緣起
4 6 3/24 TonyQ □ [閒聊] 笑談軟體測試的幾個階段（二） 測試路徑
5 6 3/25 TonyQ □ [閒聊] 笑談軟體測試的幾個階段（三） 可測試性
6 3/26 TonyQ □ [閒聊] 笑談軟體測試的幾個階段（四） 累積測資
7 4 3/27 TonyQ □ [閒聊] 笑談軟體測試的幾個階段（五） 測試權重
9 23 8/20 TonyQ □ [心得] 笑談軟體測試的幾個階段（六）歷史代碼
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ
歡迎同好到 AJAX 板一同討論。
--
確實，一排綠燈覺得自己很穩，結果不是客戶要的也沒用
推這篇正解
I prefer thread:"為什麼軟體開發者需要在意軟體品質指標"
都是好題目，總之不要陷入盲目的工具式思考。要回到命題的
本身。XDD
41
首Po想請問一下 大家工作上寫單元測試的情況 1.大部分寫完一個功能, 就馬上完成單元測試 2.先把該做的功能寫完, 再回來統一寫單元測試 3.不怎麼寫單元測試5
你講的三種我都做過，還有第四種：TDD 1. TAD，講白了就是先射箭再畫靶，如果你箭射對了那當然沒問題 但如果你一開始就射錯了還忘記拔出來，就是無效的測試 2. 同樣也是TAD，這個是我們被要求做的，code不是我們寫的、但我 們要幫其他team補測試。我主管也覺得很奇怪、我也覺得很奇怪，17
我想補一個情境 當到新公司或轉到新單位時 發現沒有在做unit test 此時身經百戰寫過上千次unit test的你 會選擇憑一己之力6
底下這是比較「野性」」的作法，算是實務專案的經驗： 其實我覺得你到一個完全沒有測試的專案，要分兩個策略: 1. 補重要主線的 integration test 反正哪邊常被報修就補哪邊。 如果一開始補不上去就先做下一點，理論上常被報修的地方會一直出現在下一點， 累積多了就可以變成1了。1
先說我不是故意要回兩篇， 但剛看到 landlord (就 joey chen, 江湖名 91) 在 FB 的回應，我覺得也蠻好的， 他說他最近在忙沒空過來，我問過他之後幫他轉過來。 以下基本上逐字照轉 (source from )2
因為大家的討論都很基於心法 實作上相對很模糊 利用這個機會也跟大家請教實作上的方式 因為最近工作被指派要針對公司產品的程式做整理，其實運作都還好 只是大家功能是一層疊一層，一堆巢狀邏輯，跟依賴中的依賴![Re: [討論] 工作上寫單元測試的比例](https://tdd.best/wp-content/uploads/2021/01/play-for-fun-scaled.jpeg "Re: [討論] 工作上寫單元測試的比例")
7
ㄅ是啊，你應該是先有需求才有測試， 通常是先假設已經在線上的已經經過線上考驗。 如果沒有這種需求，你根本就不應該整理。 我個人認為任何在沒有需求的前提下情況下整理程式碼， 是一個浪費自己時間又沒意義的行為。2
原則上要寫測試的話我會用很古老的 TDD 的方式做，先寫測試之後再寫實作。 現在的話則是寫完測試之後 Copilot 就幫我寫完一半了，然後就開始 review copilot 的 code 了。 目前經驗上能不能寫測試的話我認為有三個維度會是主要影響關鍵，提供參考： 1. 文件是否齊全16
分享最近遇到的鬼故事 當初開發完A功能後有順手寫了UT確保該功能基本能動 後來有同事在開發B功能時把他的B功能加進去我的UT default flow內 也沒有請我code review 導致我在跑UT時發現不預期的行為![Re: [討論] 工作上寫單元測試的比例](https://i.imgur.com/VBSwkjeb.jpg "Re: [討論] 工作上寫單元測試的比例")
27
[心得][英文] 如何命名「檢查」功能這週的題目是：「檢查」的相關動詞。 * 如何命名「檢查」功能？ * Check, Test, Verify, Validate 有什麼不一樣？ --- * Google 簡報23
[請益] coding style差太多怎辦?大家好 小弟上上份工作快離職前 聽到新進的同事說 他都習慣把程式寫成一個一個小的function 後來離職我花了一點時間學習設計模式17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳16
[討論] Unit test 的撰寫請益先說我對 Unit test 的看法：測試單元（可能是 function）的邏輯是否正確 好，進入正題 小弟最近剛工作，稍微讀了一下負責的 project 的程式碼後， 要開始開發 Unit test。 現況是，各個 file (.c) dependency 很重，15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言： : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言，重構都是發生在農閒的時候11
Dear Reviewer 2: Go F’ Yourself身為一個reviewer，必須分享這篇研究 Objectives The objective of this study was to empirically test the wide belief that Rev iewer #2 is a uniquely poor reviewer.5
[問卦] 用學習型AI寫程式要怎麼做？軟體開發工程師聽客戶需求後 理解分析流程後開始寫程式 最後修修改改交給客戶 深度學習的 AI 是不是能夠看數百萬個3
[請益] 如何實現單元測試多於整合測試？將單元測試實作於專案時，發現絕大部分API都是針對資料庫做CRUD，這部分程式透過in memory 寫了整合測試，越寫越覺得不對勁，心想單元測試數量不是應該要最多？ 網路文 章、影片或實體書籍大多也在探討如何寫單元測試，整合測試資源相對少，在想是不是我 哪裡做錯了，懇請各位大神指教。 --
![[心得][英文] 如何命名「檢查」功能](https://lh6.googleusercontent.com/bxkmgBIuH5ZcpuDA-s7kN1KRZ855-JbLGLKVRatL7ZyN3BhqTGmp-GKic2zYbeLJVDOLj36rzyN8Yw=w1200-h630-p "[心得][英文] 如何命名「檢查」功能")