Re: [討論] 怎樣算是一個合格的junior cpp programme

看板Soft_Job作者 (PCMan)時間1年前 (2022/08/24 22:17), 1年前編輯推噓20(20推 0噓 43→)
留言63則, 23人參與, 1年前最新討論串10/13 (看更多)
針對關於 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.cc), 來自: 111.249.189.4 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1661350664.A.083.html ※ 編輯: HZYSoft (111.249.189.4 臺灣), 08/24/2022 22:22:04
推
08/24 22:24, 1年前 , 1F
想問若是前端的話，該怎麼TDD較適合呢？觀念都理解，
08/24 22:24, 1F
→
08/24 22:24, 1年前 , 2F
但在前端常常寫一寫又拆出子組件…
08/24 22:24, 2F
→
08/24 22:27, 1年前 , 3F
抱歉這個我無法回答，我自身經驗也不夠 XD
08/24 22:27, 3F
→
08/24 22:27, 1年前 , 4F
雖然我能理解也算認同TDD的理念，但也沒辦法真的掌握它
08/24 22:27, 4F
→
08/24 22:28, 1年前 , 5F
應該不少人覺得實行起來困難，所以批評聲浪也沒停過
08/24 22:28, 5F
推
08/24 22:31, 1年前 , 6F
笑死 “Sent from PCMan on PCMan's PC”
08/24 22:31, 6F
推
08/24 22:36, 1年前 , 7F
推，最近寫UT也是很苦手，很高興可以看到此類討論
08/24 22:36, 7F
推
08/24 22:57, 1年前 , 8F
推
08/24 22:57, 8F
推
08/24 23:31, 1年前 , 9F
越靠ui的通常越難寫寫UT...至於規格不明確的確是不該怪T
08/24 23:31, 9F
→
08/24 23:31, 1年前 , 10F
DD, 只是不明確的時候應該先弄清楚再來寫XD
08/24 23:31, 10F
推
08/24 23:36, 1年前 , 11F
好想進去有走TDD的公司 感覺好讚
08/24 23:36, 11F
推
08/24 23:52, 1年前 , 12F
說真的有unit test就很好了，100%TDD執行面有困難
08/24 23:52, 12F
推
08/25 00:16, 1年前 , 13F
原來是這樣~感謝分享
08/25 00:16, 13F
→
08/25 01:28, 1年前 , 14F
前端大概或許用testing-library那種測法，內部你怎麼
08/25 01:28, 14F
→
08/25 01:28, 1年前 , 15F
拆不管
08/25 01:28, 15F
→
08/25 08:53, 1年前 , 16F
同意TDD是讓問題提早浮現，尤其edge case可能是使用到
08/25 08:53, 16F
→
08/25 08:53, 1年前 , 17F
其他api時才會發現的，不過通常需求會一環扣一環，團隊
08/25 08:53, 17F
→
08/25 08:53, 1年前 , 18F
其他人可能寧願你先寫個可以跑的東西讓他可以接下去，
08/25 08:53, 18F
→
08/25 08:53, 1年前 , 19F
而不是等到TDD流程都走完，要求團隊都有單元測試都有點
08/25 08:53, 19F
→
08/25 08:53, 1年前 , 20F
難了，還要大家都TDD實在無法想像XD
08/25 08:53, 20F
→
08/25 11:12, 1年前 , 21F
單元測試不是放在重點服務及重點功能上嗎?
08/25 11:12, 21F
→
08/25 11:12, 1年前 , 22F
真的有公司所有的程式都寫UT嗎? 實務可能嗎?
08/25 11:12, 22F
推
08/25 11:29, 1年前 , 23F
TDD很難的原因有可能是需要重構到很精簡沒有相依
08/25 11:29, 23F
→
08/25 11:30, 1年前 , 24F
才能寫出有效的測試 在開發階段寫UT就沒什麼時間了
08/25 11:30, 24F
→
08/25 11:30, 1年前 , 25F
更何況要重構 以及擔負重構衍生出的問題責任
08/25 11:30, 25F
推
08/25 11:43, 1年前 , 26F
你寫的任何程式不測試怎麼知道對不對，你把寫console lo
08/25 11:43, 26F
→
08/25 11:43, 1年前 , 27F
g跟用眼睛看結果的時間拿去寫 unit test就好了
08/25 11:43, 27F
→
08/25 12:32, 1年前 , 28F
一般真正能落實的公司，就是考管理政策推動。線上出現Bug
08/25 12:32, 28F
→
08/25 12:32, 1年前 , 29F
，不同等級，對於考績的影響是什麼，導致Unit Test，cover
08/25 12:32, 29F
→
08/25 12:32, 1年前 , 30F
age，增量覆蓋率，都有規範，避免出大錯。有了管理與考績
08/25 12:32, 30F
→
08/25 12:32, 1年前 , 31F
支持，TDD就變成增加效率的優勢了。
08/25 12:32, 31F
→
08/25 12:33, 1年前 , 32F
沒靠管理支撐品質，人都說有惰性的，絕對不覺得TDD多重要
08/25 12:33, 32F
→
08/25 12:33, 1年前 , 33F
。
08/25 12:33, 33F
推
08/25 15:50, 1年前 , 34F
結果是一張圖的時候應該沒辦法很難測吧
08/25 15:50, 34F
→
08/25 15:50, 1年前 , 35F
*應該很難測
08/25 15:50, 35F
推
08/25 16:00, 1年前 , 36F
面對隨時有隕石會砸下來的情況下TDD有用嗎?
08/25 16:00, 36F
推
08/25 16:18, 1年前 , 37F
其實越常變化或擴展測試的用處越大，不過跟 TDD 較無關
08/25 16:18, 37F
→
08/25 16:18, 1年前 , 38F
有寫就有用，不一定要 "先" 寫
08/25 16:18, 38F
推
08/25 16:46, 1年前 , 39F
TDD 可以提早驗證 API 的使用性有沒有缺陷
08/25 16:46, 39F
→
08/25 16:46, 1年前 , 40F
但並不是 API 漂亮就不會在架構上遇到問題
08/25 16:46, 40F
→
08/25 16:47, 1年前 , 41F
有時候兩邊都要顧一下會比較平衡
08/25 16:47, 41F
推
08/25 21:05, 1年前 , 42F
好奇真的有辦法先寫好unit test在開始寫程式嗎？
08/25 21:05, 42F
→
08/25 21:05, 1年前 , 43F
很多unit test都是在assert function 沒function的話
08/25 21:05, 43F
→
08/25 21:06, 1年前 , 44F
沒function的話要怎麼compile過呀 還是是說function先
08/25 21:06, 44F
→
08/25 21:06, 1年前 , 45F
宣告但內容不寫 然後先寫測試這樣嗎？
08/25 21:06, 45F
→
08/25 21:11, 1年前 , 46F
極端一點沒 function 直接寫測試也可以，要確定他會 fail
08/25 21:11, 46F
→
08/25 21:11, 1年前 , 47F
當程式有 #ifdef 的時候確實可能有些 code 根本沒 build
08/25 21:11, 47F
→
08/25 21:12, 1年前 , 48F
所以從頭到尾測試根本沒 build 到，先確定會 fail 有幫助
08/25 21:12, 48F
→
08/25 21:13, 1年前 , 49F
或是像 python，沒定義 function 也能跑 runtime 才失敗
08/25 21:13, 49F
→
08/25 21:13, 1年前 , 50F
這種也可以先跑看看確定他會 fail，確認 test 真的有執行
08/25 21:13, 50F
→
08/25 21:13, 1年前 , 51F
我自己真的有遇過 test function 沒跑到，結果假性 pass
08/25 21:13, 51F
→
08/25 21:14, 1年前 , 52F
原因是我把 function name test_xxx 拼錯成 tset_xxx
08/25 21:14, 52F
→
08/25 21:14, 1年前 , 53F
於是 python 的 unit test 沒抓到這個 test function
08/25 21:14, 53F
→
08/25 21:14, 1年前 , 54F
怎麼跑都 pass，因為根本就沒測到。所以不要覺得這很多餘
08/25 21:14, 54F
→
08/25 21:15, 1年前 , 55F
或是先寫個空的 function，跑看看確認他真的會 fail
08/25 21:15, 55F
→
08/25 21:15, 1年前 , 56F
這算是 TDD 一個重要的觀念
08/25 21:15, 56F
推
08/25 21:24, 1年前 , 57F
真的要先fail才有辦法確定他是有用的XD
08/25 21:24, 57F
→
08/25 21:25, 1年前 , 58F
我有遇到test永遠是對的 裡面對不對根本不知道
08/25 21:25, 58F
→
08/25 21:25, 1年前 , 59F
還有根本不存在資料被判斷存在，因為跟其他資料重複XDD
08/25 21:25, 59F
推
08/26 04:33, 1年前 , 60F
你有規格書就能先寫啊 沒有就只能邊做邊摸索
08/26 04:33, 60F
推
08/26 09:46, 1年前 , 61F
其實想起來也沒那麼邪，就像刷題，也是test先寫好等你
08/26 09:46, 61F
推
08/26 12:44, 1年前 , 62F
好
08/26 12:44, 62F
推
08/26 21:11, 1年前 , 63F
TDD難在要想出各種案例XD
08/26 21:11, 63F
‣ 更多 HZYSoft 的文章
文章代碼(AID): #1Z1ZC823 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 10 之 13 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共13篇)
‣ 更多 HZYSoft 的文章
文章代碼(AID): #1Z1ZC823 (Soft_Job)