看板Soft_Job
作者HZYSoft (PCMan)
標題Re: [討論] 怎樣算是一個合格的junior cpp programme
時間2022-08-24 22:17:41
針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖！重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題，TDD 不只要測試，還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序，是否一定要 TDD 這有爭議 08/23 21:34 補充一下，TDD 是還沒有開始寫任何的 code 之前，就先針對 程式寫好之後 "預期應該要有的行為" 先寫 test cases 接著，先跑一次測試親眼看著他 fail 因為還沒寫任何 code，所以測試絕對會 fail， 如果沒寫 code 卻 pass 那表示你的 test case 根本沒有測到。 接著才開始寫 code，重複跑測試直到確認 pass 為止，就是完成了。 不同於先寫 code 再測試，TDD 是顛倒，先測試再寫 code，所以才叫 test driven 如果程式被報 bug，也是先寫一個會 fail 的 test case，確認可以重現 bug 接著才開始改 code 修正，直到測試 pass 為止，就表示修好了。 這是一個觀念很特別的流派，他們的主張都是有道理的，就只是比較違反直覺不好實現。 如果你無法先寫出測試，那表示你還沒弄清楚要實作什麼行為， 或是你原先構思的 API 介面難以使用，以至於你寫不出 test case 這是強迫你釐清 spec 以及設計好介面的方法，但實在有點極端，被不少人視為邪教 XD : 推 TeaEEE: TDD最大的阻力來自你的老闆 08/24 11:40 Testing 相關的東西常常是這樣，因為一開始看不到立竿見影的成果， 花掉的資源，也沒有立刻轉成給客戶的價值，跟下水道工程一樣重要但看不見。 : 推 wulouise: TDD在需求不明確的時候寫會很痛苦，SPEC改testcase全改 08/24 12:43 : → wulouise: 但只有一個test, 還是可以加快開發的iteration, test編 08/24 12:46 : → wulouise: 譯執行時間通 08/24 12:46 : → wulouise: 通常比跑production快很多 08/24 12:46 這個事情我覺得不是 TDD 的鍋，需求不明確本身就很痛苦，TDD 只是讓你提早面對它 需求不明確或是改來改去，你連 code 該怎麼寫，寫出來該有什麼行為都不知道 自然是無法寫出 test case 的。但反過來說如果狀況是如此，你寫出的 code 會對嗎？ 錯是錯在沒定義清楚程式行為，不是 TDD 的錯。 TDD 只是一面鏡子，讓你提早發現問題，事實上這是好事。 表面上測試寫得很艱難拖慢進度，實際上是反映團隊溝通不良，和需求不清的問題 我們應該解決問題，而不是解決發現問題的人(跳過測試不做) 如果放棄做測試來節省時間，做出問題一堆的產品，這些時間後面也是要加倍還... 但也有情況例外，就是做 MVP 的時候。還來不及做測試，產品就被取消了，就免還債 XD : → foreverk: TDD比較可怕的是工程師還沒掌握domain，寫出不合理的te 08/24 14:04 : → foreverk: st case，而且自己不知道 08/24 14:04 這或許不是 TDD 的鍋，domain 掌握不足，設計出來的 API 多半也會是有問題的， TDD 並沒有讓事情更糟，只是強迫問題更早浮現罷了。 說了半天整篇都在幫 TDD 護航，但我自己大多是沒在用 TDD (汗顏...) 主要原因還是真的很難習慣，而且經驗比較不足，有時候 API 設計也是 try & error 雖然整個軟體巨觀該有什麼行為已經訂出來了，但程式會拆成很多小模組 每個模組該有哪些行為，完全端看你怎麼拆，而很多時候就是這點難以決定， 需要稍微實驗不同的作法，在這個階段強迫要先寫 test 還真有點強人所難。 但如果是定義很明確的 API，例如 web 後端的 RESTful API，介面都已經訂好了 這時候遵循 TDD 先寫 test case 完全是可行的，有興趣的朋友不妨一試! -- Sent from PCMan on PCMan's PC -- ※ 發信站: 批踢踢實業坊(ptt.org.tw), 來自: 111.249.189.4 (臺灣) ※ 文章網址: https://ptt.org.tw/Soft_Job/M.1661350664.A.083 ※ 編輯: HZYSoft (111.249.189.4 臺灣), 08/24/2022 22:22:04
推 windclara: 想問若是前端的話，該怎麼TDD較適合呢？觀念都理解， 08/24 22:24
→ windclara: 但在前端常常寫一寫又拆出子組件… 08/24 22:24
→ HZYSoft: 抱歉這個我無法回答，我自身經驗也不夠 XD 08/24 22:27
→ HZYSoft: 雖然我能理解也算認同TDD的理念，但也沒辦法真的掌握它 08/24 22:27
→ HZYSoft: 應該不少人覺得實行起來困難，所以批評聲浪也沒停過 08/24 22:28
推 Chiason: 是這個包養平台嗎 08/24 22:28
推 linnom: 笑死 “Sent from PCMan on PCMan's PC” 08/24 22:31
推 shibin: 推，最近寫UT也是很苦手，很高興可以看到此類討論 08/24 22:36
推 iankingh: 推 08/24 22:57
推 wulouise: 越靠ui的通常越難寫寫UT...至於規格不明確的確是不該怪T 08/24 23:31
→ wulouise: DD, 只是不明確的時候應該先弄清楚再來寫XD 08/24 23:31
推 Markell: 交男友跟包養有什麼差別 08/24 23:31
推 holebro: 好想進去有走TDD的公司 感覺好讚 08/24 23:36
推 wulouise: 說真的有unit test就很好了，100%TDD執行面有困難 08/24 23:52
推 viper9709: 原來是這樣~感謝分享 08/25 00:16
→ sevenHEAD: 前端大概或許用testing-library那種測法，內部你怎麼 08/25 01:28
→ sevenHEAD: 拆不管 08/25 01:28
推 fuoya: 包養網到底在紅什麼? 08/25 01:28
→ foreverk: 同意TDD是讓問題提早浮現，尤其edge case可能是使用到 08/25 08:53
→ foreverk: 其他api時才會發現的，不過通常需求會一環扣一環，團隊 08/25 08:53
→ foreverk: 其他人可能寧願你先寫個可以跑的東西讓他可以接下去， 08/25 08:53
→ foreverk: 而不是等到TDD流程都走完，要求團隊都有單元測試都有點 08/25 08:53
→ foreverk: 難了，還要大家都TDD實在無法想像XD 08/25 08:53
推 Apasiri: 有人被包養嗎 08/25 08:53
→ Wishmaster: 單元測試不是放在重點服務及重點功能上嗎? 08/25 11:12
→ Wishmaster: 真的有公司所有的程式都寫UT嗎? 實務可能嗎? 08/25 11:12
推 vi000246: TDD很難的原因有可能是需要重構到很精簡沒有相依 08/25 11:29
→ vi000246: 才能寫出有效的測試 在開發階段寫UT就沒什麼時間了 08/25 11:30
→ vi000246: 更何況要重構 以及擔負重構衍生出的問題責任 08/25 11:30
推 litidi: 求包養...管飽就好XD 08/25 11:30
推 superpai: 你寫的任何程式不測試怎麼知道對不對，你把寫console lo 08/25 11:43
→ superpai: g跟用眼睛看結果的時間拿去寫 unit test就好了 08/25 11:43
→ DrTech: 一般真正能落實的公司，就是考管理政策推動。線上出現Bug 08/25 12:32
→ DrTech: ，不同等級，對於考績的影響是什麼，導致Unit Test，cover 08/25 12:32
→ DrTech: age，增量覆蓋率，都有規範，避免出大錯。有了管理與考績 08/25 12:32
推 Merzario: 阿姨!我不想努力了(求包養) 08/25 12:32
→ DrTech: 支持，TDD就變成增加效率的優勢了。 08/25 12:32
→ DrTech: 沒靠管理支撐品質，人都說有惰性的，絕對不覺得TDD多重要 08/25 12:33
→ DrTech: 。 08/25 12:33
推 art1: 結果是一張圖的時候應該沒辦法很難測吧 08/25 15:50
→ art1: *應該很難測 08/25 15:50
推 Muzaffer: 有沒有富二代要包養我 08/25 15:50
推 testPtt: 面對隨時有隕石會砸下來的情況下TDD有用嗎? 08/25 16:00
推 lovdkkkk: 其實越常變化或擴展測試的用處越大，不過跟 TDD 較無關 08/25 16:18
→ lovdkkkk: 有寫就有用，不一定要 "先" 寫 08/25 16:18
推 CRPKT: TDD 可以提早驗證 API 的使用性有沒有缺陷 08/25 16:46
→ CRPKT: 但並不是 API 漂亮就不會在架構上遇到問題 08/25 16:46
推 MIJice: 身邊有朋友被包養嗎 08/25 16:46
→ CRPKT: 有時候兩邊都要顧一下會比較平衡 08/25 16:47
推 henry4343: 好奇真的有辦法先寫好unit test在開始寫程式嗎？ 08/25 21:05
→ henry4343: 很多unit test都是在assert function 沒function的話 08/25 21:05
→ henry4343: 沒function的話要怎麼compile過呀 還是是說function先 08/25 21:06
→ henry4343: 宣告但內容不寫 然後先寫測試這樣嗎？ 08/25 21:06
推 SpyTime: 亞洲最大包養平台上線了 08/25 21:06
→ HZYSoft: 極端一點沒 function 直接寫測試也可以，要確定他會 fail 08/25 21:11
→ HZYSoft: 當程式有 #ifdef 的時候確實可能有些 code 根本沒 build 08/25 21:11
→ HZYSoft: 所以從頭到尾測試根本沒 build 到，先確定會 fail 有幫助 08/25 21:12
→ HZYSoft: 或是像 python，沒定義 function 也能跑 runtime 才失敗 08/25 21:13
→ HZYSoft: 這種也可以先跑看看確定他會 fail，確認 test 真的有執行 08/25 21:13
推 Toth: 這個包養網正妹好多 是真的嗎 08/25 21:13
→ HZYSoft: 我自己真的有遇過 test function 沒跑到，結果假性 pass 08/25 21:13
→ HZYSoft: 原因是我把 function name test_xxx 拼錯成 tset_xxx 08/25 21:14
→ HZYSoft: 於是 python 的 unit test 沒抓到這個 test function 08/25 21:14
→ HZYSoft: 怎麼跑都 pass，因為根本就沒測到。所以不要覺得這很多餘 08/25 21:14
→ HZYSoft: 或是先寫個空的 function，跑看看確認他真的會 fail 08/25 21:15
推 Asterix: 真的有這麼多人在找包養嗎 08/25 21:15
→ HZYSoft: 這算是 TDD 一個重要的觀念 08/25 21:15
推 wulouise: 真的要先fail才有辦法確定他是有用的XD 08/25 21:24
→ wulouise: 我有遇到test永遠是對的 裡面對不對根本不知道 08/25 21:25
→ wulouise: 還有根本不存在資料被判斷存在，因為跟其他資料重複XDD 08/25 21:25
推 mmonkeyboyy: 你有規格書就能先寫啊 沒有就只能邊做邊摸索 08/26 04:33
推 AdamShi: 有人可以分析一下包養平台的差異嗎 08/26 04:33
推 CYHyen: 其實想起來也沒那麼邪，就像刷題，也是test先寫好等你 08/26 09:46
推 zebraseven: 好 08/26 12:44
推 SHANGOYANYI: TDD難在要想出各種案例XD 08/26 21:11
→ bnd0327: TDD在做自己私人專案的時候比較好用，因為自己寫的本來就 08/30 14:38
→ bnd0327: 比較隨興，用TDD方法一步一步做比較不會放飛自我 08/30 14:40
推 lezabo: 那個包養網人最多XD 08/30 14:40
推 akira01: 個人的經驗,一堆人在等你的code才能繼續下去,一個禮拜過 09/02 07:20
→ akira01: 去了,這時只說我由於用tdd只完成了測試程式,會遭人白眼, 09/02 07:20
→ akira01: 所以通常我們還是會先完成功能再補測試程式 09/02 07:20
推 superpai: tdd是測試跟實作交替寫，會說測試先寫完就是做錯了 09/02 07:35
→ HZYSoft: 測試先寫是針對要改動的地方，不是整個系統都只先寫測試 09/02 21:47
推 silberger: 我妹上包養網被我發現= = 09/02 21:47
→ HZYSoft: 實務上確實是交替進行沒錯 09/02 21:47
→ longlongint: TDD不會升遷啦，寫爛code升遷學弟接手讚讚（反串） 09/11 20:49
推 jackhsien: 個人經驗TDD 適合需求明確的開發 不然光改測資就耗掉一 09/16 10:44
→ jackhsien: 堆時間 09/16 10:44