#純靠北工程師526
----------
最近開始面試工程師,發現幾個問題:
1. 英文。比起其他國籍像泰國,越南,新加坡,印尼的面試者,發現台灣的面試者會一直叫面試官重複問題,雖然可能雙方都有口音問題,但是比較起來,台灣的工程師真的多好幾次,也看到我同事因為這個而扣分。
2. 套件過度依賴。一直強調某 library 多好用,幫你解決很多問題,但是很少能解釋背後的問題具體要怎麼解決。
3. 很喜歡講一些 Buzz words。
說知道 TDD 是什麼,但是問具體的步驟,卻說和一般 unit test 一樣。不是應該要寫測試,先讓測試 failed,才開始寫功能嗎?
或者像 uncontrolled 組件,但是卻沒辦法解釋與 controlled 的差別與各自的好處
我很想讓更多台灣人加入我司,希望這樣的分享能讓面試的品質更好 QQ
----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層!
👉 https://discord.gg/tPhnrs2
----------
💖 全平台留言、文章詳細內容
👉 https://init.engineer/cards/show/6558
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「unit test是什麼」的推薦目錄:
- 關於unit test是什麼 在 純靠北工程師 Facebook 的最佳貼文
- 關於unit test是什麼 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
- 關於unit test是什麼 在 91 敏捷開發之路 Facebook 的最讚貼文
- 關於unit test是什麼 在 コバにゃんチャンネル Youtube 的最佳解答
- 關於unit test是什麼 在 大象中醫 Youtube 的最佳貼文
- 關於unit test是什麼 在 大象中醫 Youtube 的最佳貼文
- 關於unit test是什麼 在 [討論] 多少公司有執行單元測試分享- 看板Soft_Job 的評價
- 關於unit test是什麼 在 Unit Test 定義是什麼, 涵蓋的範圍又是哪些? 的評價
- 關於unit test是什麼 在 java unit test教學的推薦與評價,FACEBOOK和網紅們這樣回答 的評價
- 關於unit test是什麼 在 【 .NET 測試入門】#1 什麼是單元測試& 整合測試& 端對端測試? 的評價
unit test是什麼 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
今天不聊科技,來聊聊日常工作中的優先度選擇。
作者認為每當你對一件事情說 Yes,其實你就是對其他的事情說 No,因為我們時間有限,不可能每件事情都想要盡善盡美,而那些被你自動說 NO 的事情,其實有些可能反而能夠為你帶來更大的效益。
整篇文章都圍繞於機會成本的概念,探討到底什麼是機會成本,其中顯性機會成本以及隱性機會成本的差異是什麼。
就我個人來看,其實日常工作中也是充滿各種選擇,舉例來說,今天要有一個新的專案要開發,你要負責對其處理 CI/CD 等相關工作,你會怎麼安排自己的 Task ? 這些彼此間的優先順序會怎麼選擇?
也許你腦中會想到有下列的事情要完成
1. 打通 CI/CD 流水線
2. 完善 CI 系統,增加各種檢查,譬如 unit test, linter 或是其他種類
3. 完善 CD 系統,自動上版本,自動更新
但是仔細看會發現,其實(3)這點真的一開始就可以辦到嗎? 需不需要一個手動部署的版本先撐住? 然後根據這些結果再跟(2)去比較,到底開發團隊一開始需要什麼?
其實時間有限的情況下,我們往往都需要進行選擇,困難的是這些選擇永遠都沒有一個標準答案,不同團隊不同環境下,相同選項都會有不同答案。
我個人也滿認同作者提到的概念,時間有限,將精力與時間放到更具有價值的開發與工作上,那些可以展現你個人價值與光芒的工作,未來可能都會是你職涯的推手。
更多的工作團隊中,你的價值是自己帶出來的,而不是別人指派給你的,因此我認為如果你有機會獨當一面去處理一系列的工作,如何展現出你的價值就是一個值得訓練也值得培養的能力與議題
原文:
https://dariusforoux.medium.com/say-no-anything-thats-not-a-priority-9ed70064d0b6
unit test是什麼 在 91 敏捷開發之路 Facebook 的最讚貼文
《修改軟件的藝術》
進行一個預期九個月的專案,到第八個月時,我們發現進度比預期晚了六個月。問題在哪?怎麼會變成這樣的呢?
其實我們一直是晚了六個月,只不過我們到第八個月才發現罷了。
—
敏捷迭代的重點,讓你不斷再次確認目標是否產生變化,是否要調整方向步伐,我們是否能如預期般達成目標。
如果不行,在目前的情況下,我們能做什麼是最有價值的行動呢?
在這過程中,避免因為工作任務顆粒度過大,導致資源無法釋放,無法因應變化去選擇有更價值的工作進行,因此承擔機會成本。抑或是得把已經投入資源進行開發,卻仍無法產生價值的半成品放一旁,因此承擔了沈沒成本。
越早發現問題,修復問題的成本與風險越低。頻繁確認目標以及實際的落差、頻繁交付價值、調整行動,這才能應對現代軟體產品的變化性。
我喜歡這本書,也推薦給想要體會在遺留代碼系統中的敏捷實踐為何的朋友。九個實踐如下:
1) 在問如何做之前,先問為什麼做、給誰做、做什麼。(user story template)
2) 小批次建置,每一段之間都是自動化的鐵路,異動量少,建置發生問題時,根本原因越容易找出來,能得到更快的 feedback ,就能更快的做出反應。
3) 持續整合(Continuous Integration), 持續整合說真的跟 build solution 用哪一套的關係不大,重點在團隊能在多快的時間內讓大家寫的程式變成一份並確認執行無誤。
持續整合的有效性與即時性也絕對跟你團隊的分支策略有關。(建議基於主幹的開發)
4) 協作,如何透明順暢頻繁地溝通,又不會花太多無謂的溝通成本,如何確保大家的程式碼理解一致、閱讀無誤。extreme programming 裡面有非常多良好的實踐可以解決這些問題。
5) write clean code,高內聚、低耦合,職責明確,互動簡單,意圖清楚。(簡單設計simplicity 的四條原則)
6) 測試先行,test first, 其實是 think first, identifying requirements first. 在你動手寫產品程式碼之前,總要先搞懂需求的期望是什麼,需求怎樣叫完成。
要滿足使用者哪些情境,才叫符合預期。(這就是驗收測試驅動開發, ATDD)
這才是我們為何要寫程式的目標,接著以終為始,從 ATDD 往下 drill down 多個 TDD 循環以完成所有情境的程式碼,並在每個 TDD 循環中,一分不多一分不少的把力氣花在該花的地方上,並且在每一次的綠燈情況下進行重構。(包含測試程式)
這,才是實務上會 work 的 TDD,這才是為什麼 TDD 是種開發方法論,而不是測試方案。
7) 用測試描述行為,事實上 test-first + test as scenario, 怎麼把繁複的需求功能抽絲剝繭成關鍵情境,並進行排序來達到 baby step 的效果,到這邊6+7 就是 實例化需求(specification by examples)+驗收測試驅動開發(ATDD)+測試驅動開發(classic TDD, 紅燈、綠燈、重構)
8 ) 最後實現設計,意圖導向設計,重構、重構、重構,你得知道怎麼辨識出 code smell, 你得知道重構技巧,你得知道怎麼用最短時間、最低風險,正確地重構你的設計,來讓用的人很好用,看的人很好懂,改的人很好改。
這邊要避免不必要的過度設計,又是一整門學問了。(過度重構也是一種浪費,通常是以 #過度解耦 的模樣呈現。)
9) 從遺留代碼中學習,耐住性子去尊重這些遺留代碼。他們過去有其存在的價值與原因,至少你的薪水可能就是這堆線上又髒又臭的代碼在幫你賺的。
一定要壓抑住自己重寫系統或功能的衝動。
重寫跟重構不一樣的,重寫在實務跟價值上是不會 work 的。
而且,如果每次碰到遺留代碼就想重寫,你就永遠無法具備重構實務產品的能力。
當然,重構之前一定要有測試保護,這也是為什麼你該學的單元測試,是 #針對遺留代碼 如何優雅低風險低成本的加入單元測試。
沒有單元測試的保護,沒有單元測試提供的反饋(自己能做到的獲得最快的反饋實踐就是單元測試),就無法「快速進行較進階的重構」
—
當然,以上有蠻多是書裡沒提到的細節,也是我上課會提到、甚至設計成 workshop 的內容。
寫著寫著沒想到寫這麼多,沒辦法,共鳴點太多了,裡面真的沒啥廢話,也沒啥太打高空的東西。
都是扎扎實實該落地的實踐,要想當個基本功紮實、穩定輸出戰力,要想領的比別人多,就得比比別人具備更多能產生價值的能力。
不要再被你身邊的環境或公司受限住了,那都是你下意識給自己的藉口理由。
你覺得這些東西在你現在的公司工作用不上,所以你不想學。
但因為你不學、不會,又怎麼進得去把這些東西發揮地淋漓盡致的公司呢?人家怎麼會願意用你呢
👉 修改軟件的藝術,請參考 天瓏資訊圖書 上的介紹, https://www.tenlong.com.tw/products/9787115467768
※ 對實踐 5,6,7,8,9 有興趣,想透過實作了解的更透徹的朋友,可以參考底下兩門培訓:
1)演化式設計:測試驅動開發與持續重構 202009,https://dotblogs.com.tw/hatelove/2020/05/08/202009-Evolutionary-Development-TDD-and-Continuous-Refactoring
2)【針對遺留代碼加入單元測試的藝術】202011,https://dotblogs.com.tw/hatelove/2020/05/08/Unit-testing-effectively-with-legacy-code-202011
unit test是什麼 在 コバにゃんチャンネル Youtube 的最佳解答
unit test是什麼 在 大象中醫 Youtube 的最佳貼文
unit test是什麼 在 大象中醫 Youtube 的最佳貼文
unit test是什麼 在 Unit Test 定義是什麼, 涵蓋的範圍又是哪些? 的推薦與評價
什麼是Unit Test? · 驗證一小段的程式碼, 並以驗證單一行為為主, 就是unit of behavior · 執行快速 · 獨立性(isolated) 不受其他unit test 影響. ... <看更多>
unit test是什麼 在 【 .NET 測試入門】#1 什麼是單元測試& 整合測試& 端對端測試? 的推薦與評價
NET 測試入門】#1 什麼是單元測試& 整合測試& 端對端測試? ... JavaScript Testing Introduction ... ... <看更多>
unit test是什麼 在 [討論] 多少公司有執行單元測試分享- 看板Soft_Job 的推薦與評價
關於自動化測試可以參考我多年前的拙作
https://www.ptt.cc/bbs/Soft_Job/M.1338221262.A.0AC.html
不過現在我們在討論單元測試,所以我將把我的文章內容縮小到「單元測試」
上面。
我待過四間公司,寫過C#, PHP, Python, Java,而這四家公司不管小接案公司
,網路公司,跨國軟體公司或是大型傳統產業,通通都沒有養成所有人普遍撰寫
單元測試的習慣,倒是我聽說一些朋友在比較偏小型的start up或是小型軟體
公司,比較有在做Unit Test。
很多人在談Unit Test的時候會把Unit Test跟Integration Test混在一起,然後
說Unit Test要付出很多effort,實際上,他是把Unit Test跟Integration Test
混在一起講了。
雖然這些這些公司都因為種種原因沒有做Unit Test的習慣,但是我在這四間公司
裡面全部都有自己做Unit Test,而即使有做Unit Test,我的品質與速度都比其
他人要快。
很多人在做Unit Test有一個盲點,就是為了做單元測試而做單元測試,因為上面
一個方案下來,說我們的專案要有幾個test case,要達到多少coverage rate,
這樣才叫做品質好,卻經常沒有從Unit Test的ROI出發。
另外一項造成Unit Test會花上許多時間的原因,就是物件的依賴程度太高,又
不懂得使用Mocking技術或是沒有讓程式有足夠的測試力,導致做單元測試會影響
到整體開發時程,這樣單元測試就變成累贅了。
「你終究要測試你的程式的,為什麼不做單元測試呢?」
如果你的單元測試是為了減少你的測試時間用的,減少測試時間進而減少整體
開發時間,那你為什麼不做呢?
給一些還沒有做單元測試的朋友一些體會到單元測試的切入點:
1. bug的單元測試
如果發現bug,嘗試用單元測試的方式找到那段有問題的程式碼,然後撰寫一個
單元測試程式,以後迴歸測試時要執行這個測試。
2. 減少耗時的I/O
network, storage這些東西都會造成你後續測試的時候消耗很多時間,透過mocking
技術, 機制將這些I/O的部分都去除掉,每次測試執行時間可能從幾分鐘縮短到幾秒
,這會是天差地別的差距。
3. 選擇依賴關係高的程式來做
很多人在寫單元測試的時候會挑外圍的程式來說,這些外圍程式大多沒有太多的依賴
關係,所以出問題的機會也少,程式也相對容易理解,反觀那些高依賴關係的程式,
由於跟其他類別之間大量耦合,要測試裡面的內容相對來說困難許多,透過mocking
來切割待測類別與其他類別之間的依賴關係,這樣就不用花這麼多時間準備整合測試
資料。
反觀依賴度低的類別,測試資料準備與驗證相對簡單,雖然做單元測試也快,但ROI
卻很低,做久了,會很沒有成就感。
4. 思考單元測試減少的載入時間
除非你有用JRebel或是類似的東西,否則你在開發Spring Java程式的時候不免必須
不斷restart你的application或是你的container去bootstrap Spring managed beans
,這些在測試階段會花上非常多的時間。
當然Spring有提供JUnitRunner或AbstractTestNGSpringContextTests來供你產生單元
測試用的spring context,但當你類別多的時候還是很花時間的,這時候如果透過具備
Mocking功能的單元測試來完成你程式碼的測試作業,將可以大幅縮短之後的測試時間。
以上這幾點達到的測試覆蓋率可能不太高,但你應該會找到程式要測試的重點,至於
單元測試是要程式開發前(TDD)或是開發之後做,這要看你使用什麼樣的mocking技術。
重點是不要為了去做Test而去Unit Test,重點是分析這樣做以後能達到多少ROI。
最後再來談談「單元」,每個人對於單元的定義可能都有所不同,但基本上的認知是,
單元測試是在測試「程式碼」最小界定範圍為「一個function」或是一個類別,所以
單元測試的目的在於測試function或class是否有達到預期。
當然function或class之間是有dependency存在的,單元測試的目的是去除這些
dependency讓整個測試可重複執行並且不會因為其他單元的問題或不存在而造成
待側單元的錯誤。事實上我認為單元測試最大的關鍵是怎麼透過各種方法去消滅
這些dependency的能力,實際上你學的不是測試方法,而是mocking方法。
如果你是用Java的話推薦使用無敵mocking framework JMockit,完全不用對你
現有的程式進行改造,一樣可以mocking。
其他透過撰寫測試的過程當中知道怎麼樣去規劃元件之類的好處我就不說了,
台灣這邊的軟體產業之所以會有種種問題,一部分就因為對於unit test帶來
的好處與方法沒有正確的認知所導致。
--
~四十八個德瑞克~https://blog.derekhsu.homeip.net
馬皇本紀:https://blog.derekhsu.homeip.net/2009/08/821
藍澤光的身世之謎:https://blog.derekhsu.homeip.net/2010/09/1610
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.181.111.225
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1478187696.A.46A.html
那就叫做integration test,不是unit test。
至於要不要重構這件事,如我所說,這跟你用的是什麼mocking tool有關,如果是
JMockit,那別擔心,你的程式就算是垃圾都不用重構也可以去除所有dependeny來做
unit test。
如果沒有這種framework可以用(C# https://www.typemock.com/isolator-product-page
這個可以試試看,但這是commerical的),unit test帶來的好處是refactor之後的
更好的系統架構。
※ 編輯: derekhsu (175.181.111.225), 11/03/2016 23:54:43
... <看更多>