中秋佳節連假,看著一堆人出遊的新聞,然而還是有一大群熱血的夥伴,在連假中一起在線上進行了【#針對遺留代碼加入單元測試的藝術】以及【#極速開發】的培訓。
這是第一次採線上直播的進行方式,在上課前因為之前有錄 Classic TDD by Example 無限次觀看的影音課程的經驗,比較能掌握在螢幕上該怎麼解說、標記、highlight 重點。
而這次課前也跟同事和夥伴們事先練習過,如何用 zoom 來安排互動、討論、上課下課之間流暢度的配合,所以都還蠻順利的。
唯一就是開了6個 IDE 再加上 zoom 的直播當下,memory 跟 cpu 在 live coding 過程中,跑單元測試需要等待的時間拉長了,甚至 6 個 IDE 時 intellisense 出來的速度跟不上我的手速(後來關到剩下4個)
陪家人團聚很重要,讓自己進步也很重要,疫情肆虐下要恢復過去的生活已經幾乎不可能了,但工作機會卻因此越來越險峻,怎麼投資自己,怎麼讓自己更加熟悉線上/遠端的協作,還是很重要的。
感謝陪伴我第一次正式線上直播課的所有學員,謝謝你們即使在遠端,仍積極參與、發問,還有課後的練習。
※ 極速開發課上完當晚,就有學員錄好第一版練習影片找我 review 了,今天是第二天,已經有六位同學交了第一版作業。看到大家都這麼熱血,我也跟著沸騰起來了。
投資自己不嫌晚,但最怕沒跨出第一步,你不需要一開始就很強,但你需要開始才能變強。
也謝謝好夥伴 Cash Wu Geek 在線上幫忙顧前顧後,有你的協助,讓兩天課得以進行地更順利完整。
同時也有1部Youtube影片,追蹤數超過7萬的網紅在地上滾的工程師 Nic,也在其Youtube影片中提到,現在學習知識的渠道越來越多,無論對於零基礎或是有經驗的工程師,想要持續成長應該看書還是看影片來的更有效率呢? 主要會和你分享我過去從新手到資深的過程中,如何持續保持進步及學習的經驗 也許這個經驗可以幫助到你,也歡迎留言和我分享你的看法 相信彼此分享不同的學習見解,能讓對於想要更精進自己程式開發...
「單元測試的藝術」的推薦目錄:
- 關於單元測試的藝術 在 91 敏捷開發之路 Facebook 的最讚貼文
- 關於單元測試的藝術 在 91 敏捷開發之路 Facebook 的最佳貼文
- 關於單元測試的藝術 在 91 敏捷開發之路 Facebook 的精選貼文
- 關於單元測試的藝術 在 在地上滾的工程師 Nic Youtube 的最佳貼文
- 關於單元測試的藝術 在 [討論] 多少公司有執行單元測試分享- 看板Soft_Job 的評價
- 關於單元測試的藝術 在 單元測試的藝術閱讀交流 - Facebook 的評價
- 關於單元測試的藝術 在 單元測試的藝術第二版The Art of Unit Testing 2nd Edition 的評價
- 關於單元測試的藝術 在 LaraDiner #40 - [單元測試的藝術] 第五.六章PHP 實作範例 的評價
- 關於單元測試的藝術 在 單元測試的藝術在PTT/Dcard完整相關資訊 的評價
- 關於單元測試的藝術 在 單元測試的藝術在PTT/Dcard完整相關資訊 的評價
- 關於單元測試的藝術 在 [精進] [線上] 單元測試的藝術-讀書會- 看板StudyGroup 的評價
- 關於單元測試的藝術 在 單元測試的藝術在PTT/Dcard完整相關資訊 - 萌寵公園 的評價
- 關於單元測試的藝術 在 單元測試的藝術在PTT/Dcard完整相關資訊 - 萌寵公園 的評價
單元測試的藝術 在 91 敏捷開發之路 Facebook 的最佳貼文
【課程更新公告】
➀ 20210918 (六): 針對遺留代碼加入單元測試的藝術
➁ 20210919 (日): 極速開發
這兩門課因應疫情第二級管制,且九月學校剛開學更容易潛藏傳染風險,加上活動場地不允許室內用餐,且須梅花座、維持社交距離、避免直接的交流,加上室內上課時間長度與空氣流通問題,將改為「線上直播上課」搭配「未來實體課程/活動 回鍋」的方式,以便各位在原訂日期能即時獲得上課內容,且未來實體活動可補齊應有之上課效果。
還請有報名這兩門課的學員,檢查一下信箱,如您沒收到此通知信,請務必檢查一下垃圾信件,因為保護各位的 email 資訊,大量密件副本(bcc) 加上信件內容有些連結,容易被判定成垃圾信件。
如果還是沒有,請私訊我,我會盡快協助處理。
--
圖片來源:Photo by Patrick Fore on Unsplash
單元測試的藝術 在 91 敏捷開發之路 Facebook 的精選貼文
疫情當下,應收到位,感覺就像飢渴的水庫,等了很久的梅雨終於來臨。
感謝各位好客戶來了一場及時雨。
也謝謝許多報名公開課的朋友不離不棄,我已經針對公開課在著手準備配套措施,已經跟其他 Odd-e 同事商討了一番,相信大家會很滿意這樣的進行方式。
先 announce 基本資訊:
1. 【#針對遺留代碼加入單元測試的藝術】與【#極速開發】,準備著手進行 線上直播 上課的進行方式。目的有幾個:
➀ 因應疫情的不確定性,線上課可以避免實體上課的染疫風險,也可以讓已經報名的同學,可以在期望的時間內,先得到培訓的內容。
➁ 有些朋友在國外想上課,有些朋友週末得在家不能出門,有些朋友總是搶不到實體課的報名,他們能透過線上課,及早獲得他們想學習到的內容。
.
2. 因為 實體課 還是會有一些效果是 線上課 不容易達到的,所以:
➀ 每一門線上課所對應的實體課,我都會提供 2 個以上的免費名額,給參加過線上課程的同學得以參加實體課,可以當作再一次的複習,也能補足 線上與實體課 完整的內容。(每梯次名額有限,一樣先搶先贏。但至少已經參加過完整的線上直播內容了,即使沒搶到也不會有太大問題)
➁ 參加實體課的同學,在實務上練習應用一陣子之後,未來如果想回鍋複習,想帶著問題再來參加一次課程,則可以來找我報名 線上課。
這樣一來,線上課能讓更多想變強的朋友,更即時學習到想學的內容,也比較沒有時間空間限制,同時也讓他們享有參加實體課的資格,可當作複習,也可以感受實體課不一樣的效果。
而實體課的朋友,不用擔心一次的資訊量過大,想報名第二次把第一次沒學全的部份了解更完整,卻還搶不到位置。線上課可以當作回鍋票的備案,讓大家上完課經歷過實務的歷練之後,能有機會再來打通一次任督二脈。
.
3. 為避免線上課程被一些環境相關問題卡住太久,所以預計會有暖身場,例如週末的課,在週三晚上先 host 一場線上暖身,一起動手寫些程式,來確保 zoom, 網路, 視訊, 麥克風, IDE 等環境沒有問題。
最後,線上課我會跟實體課一樣限定人數,才能維持一定的品質與效果。因為我並不是為了規模化、為了賺更多的錢才搞成線上的,因應疫情,因應之前眾多學員的 request,想在 實體課 跟 線上課 兩者之間取得最大綜效,才做出這樣的決定與轉變。
也希望大家可以繼續支持我,希望我們能讓更多人用正確、精準、快速、快樂的方式,進行軟體開發。
.
最後,這兩門課已經因為疫情被延期的朋友請放心,等我準備好,我會第一時間詢問你們,是否想先參加線上課,未來再回鍋參加實體課。
希望這樣的方式,能滿足更多朋友的需求,以及即時性。(我感受到大家對那種半年前要先報名,半年後才可以上課,感覺到相當不滿。還因為疫情再延期下去,離報名都快一年了)
讓我們一起加油吧 ❤
單元測試的藝術 在 在地上滾的工程師 Nic Youtube 的最佳貼文
現在學習知識的渠道越來越多,無論對於零基礎或是有經驗的工程師,想要持續成長應該看書還是看影片來的更有效率呢?
主要會和你分享我過去從新手到資深的過程中,如何持續保持進步及學習的經驗
也許這個經驗可以幫助到你,也歡迎留言和我分享你的看法
相信彼此分享不同的學習見解,能讓對於想要更精進自己程式開發功力的人有很大的幫助
===章節===
00:00 哪一個有效律?
00:36 寫程式如同寫作
05:14 書是最便宜的資源
10:14 折扣碼操作示範
===蝦皮購書折扣碼===
折扣碼:FLAGNIC36
時間:2021-03-29 ~ 2021-06-29
折扣碼:FLAGNIC79
時間:2021-06-30 ~ 2021-09-30
折扣碼: FLAGNIC11
時間:2021-10-01~ 2021-12-31
===前陣子在看的推薦書單===
(零基礎)
- 白話演算法!培養程式設計的邏輯思考
- Python 刷提鍛鍊班
(中高階)
- 設計模式之禪(第2版)
- 無瑕的程式碼-整潔的軟體設計與架構篇
- 單元測試的藝術
- 演算法之美:隱藏在資料結構背後的原理(C++版)
- Kent Beck的實作模式
(Ruby)
- Writing Efficient Ruby Code
(成長思考)
- 圖解.實戰 麥肯錫式的思考框架:讓大腦置入邏輯,就能讓90%的困難都有解!
- 師父:那些我在課堂外學會的本事
- 高勝算決策:如何在面對決定時,降低失誤,每次出手成功率都比對手高?
- 窮查理的普通常識
- 懶人圖解簡報術:把複雜知識變成一看就秒懂的圖解懶人包
- 寫作,是最好的自我投資
喜歡影片的話!可以幫忙點個喜歡以及分享、訂閱唷!😘
━━━━━━━━━━━━━━━━
🎬 觀看我的生活廢片頻道: https://bit.ly/2Ldfp1B
⭐ instagram (生活日常): https://www.instagram.com/niclin_tw/
⭐ Facebook (資訊分享): https://www.facebook.com/niclin.dev
⭐ Blog (技術筆記): https://blog.niclin.tw
⭐ Linkedin (個人履歷): https://www.linkedin.com/in/nic-lin
⭐ 蝦皮賣場: https://shopee.tw/bboyceo
⭐ Github: https://github.com/niclin
⭐ Podcast: https://anchor.fm/niclin
━━━━━━━━━━━━━━━━
✉️ 合作邀約信箱: niclin0226@gmail.com
#寫程式 #前端 #後端
![post-title](https://i.ytimg.com/vi/a50in7kCbzo/hqdefault.jpg)
單元測試的藝術 在 單元測試的藝術閱讀交流 - Facebook 的推薦與評價
針對《單元測試的藝術》一書的閱讀、討論與實務單元測試交流。 ... <看更多>
單元測試的藝術 在 單元測試的藝術第二版The Art of Unit Testing 2nd Edition 的推薦與評價
The-Art-of-Unit-Testing Reading Digest. ... <看更多>
單元測試的藝術 在 [討論] 多少公司有執行單元測試分享- 看板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
... <看更多>