Search
#單元測試的藝術_第二版，繁體中文版要上市啦！
據出版社說，預計下月初前就可以買到了，敬請期待！
---
這是我看過寫單元測試寫得最好的一本書，沒有之一。
也因為我很愛這本書，這本書也是影響我在單元測試、測試驅動開發，以及設計和重構領域很深的一本書，說是整個系列的起點也不為過。
我也真心認為，台灣的軟體業需要這本書，來幫助大家了解單元測試的全貌，以及實務上的單元測試的模樣。
所以當時與博碩推薦這本書很值得翻譯時，博碩的總編也與國外簽下了這本書的版權，我當然就自動請纓將這本經典好書翻譯成繁體中文。
裡面雖然以C#當例子，但觀念都是通的，真心推薦給大家！
#單元測試
#真心不騙 #人品推薦
想在 30 分鐘內學會 Git 嗎？看這裡就對了！
Git 是一種「原始碼版本控制」軟體，它可以儲存原始碼每個版本之間的差異，然後您可以要求「時光回溯」到任何指定的版本。這可以防止一天到晚改規格的客戶或老闆，在您辛苦更動原始碼後，來一句要命的：「還是之前的那一版比較好」。我個人認為，它是程式設計中，最重要的 7 大軟體之一（文字編輯器、編譯器、版本控制器、自動化建構系統、單元測試軟體、環境佈建系統、與除錯器）。
這類「版本控制軟體」，依照流行先後，著名的有 CVS、Subversion、與 Git。目前最流行的版本控制軟體是「Git」，流行原因多多少少是因為 Linux 核心（Linux Kernel）原始碼，就是用這套軟體保持各個版本差異的。不少公司也要求程式設計師寫好原始碼後，一律都得回存 Git 系統才算完工，不能只是存在私人的硬碟就了事。所以 Git 就變成業界必備的軟體之一。
補習班常常有同學問我，有沒有那種很簡單的 Git 說明書，不用講太深，但要在 30 ~ 60 分鐘內就掌握常用功能的教材？之前一直找不到，不過今天幫大家找到了！還有中文版喔！叫做「Git 簡明指南」。鏈結如下：
https://rogerdudler.github.io/git-guide/index.zh.html
其實它的原文名稱有點好玩：「Git - The Simple Guide, No Deep Shit!」。這類標題通常能騷動我個性中愛作怪的小惡魔，讓我會心一笑後點進去看看。看完後，果然「一點點深的便便」都沒有... XD 還有中文版（簡中）！心想這麼讚的東西不介紹怎麼行！就花時間寫了這一篇。
希望今天的分享對各位的日常工作有幫助！我也很鼓勵大家能找到適合自己的「七大系統」，把它弄熟。畢竟「工欲善其事，必先利其器」嘛！我個人習慣使用的七大系統，也列在底下讓大家參考：
1. 文字編輯器：vim。不好學，但游標移動速度與文字操控能力超快！
2. 編譯器：gcc。因為我寫 C 語言比較多，所以用 gcc。
3. 版本控制器：git。其實我之前是熟 subversion。不過 git 也很好用喔！
4. 自動化建構系統：make。可以把編譯、安裝...等囉哩八唆的指令濃縮成一個簡稱（如：build, install...等）。打完按下 enter 後就可以去泡咖啡了！還能偵測哪些原始碼已經編譯過，不需重新編譯已縮短作業時間。
5. 單元測試軟體：CUnit。嚴格來說，這算一套「函式庫」，可以針對你寫好的原始碼做測試。由於我寫 C 較多，所以用 CUnit。如果您寫的程式碼是 Java 或其它，可能得找相對應的測試軟體。
6. 環境佈建軟體：VirtualBox。用它的原因是 Win, Mac, Linux 全平台都支援。我會把程式設計環境灌好後的 VirtualBox 映像檔保存好，每次要乾淨環境就 new 一個新的虛擬機起來。最近迷上 Vagrant，想知道 Vagrant 是什麼的可以看這篇： http://goo.gl/29mBs9
7. 除錯器：gdb。雖然是文字介面，但連線到運算能力很差的開發板上想除錯，也只有 gdb 跑得動。用久了也習慣了。
其實最近還想加上第八項「(8) 軟體部署系統：Docker」，不過還在研究，也還沒熟悉。等熟悉了再跟大家報告。 :-)
如果覺得文章不錯，還煩請各位不吝按讚打賞或分享一下喔！ m(^ ^)m
我們 PaGamO/BoniO 最近開始新的產品開發，目前開始有新的工作機會（新進前端工程師、資深前端工程師），歡迎對改變教育有熱忱，對前端開發工作有專長的朋友加入我們。我們一同開發幫助大家提升學習動機的教育科技產品！
（歡迎分享）
---------
職稱：Junior FrontEnd工程師
【技能要求】
1.必備：
a. 有能力撰寫簡潔且高效的Javascript程式碼
b. 熟悉git操作以及有與其他開發者、設計師和產品經理共事的經驗
c. 熟悉HTML/CSS切版，可以依照設計文件做出準確的樣式排版
2.加分：
a. 有過任一前端框架（React、Angular、Vue等）實作的經驗
b. 有過撰寫前端單元或E2E測試的經驗
【工作內容】
1. 與產品經理和設計師溝通，進行雲端產品開發
2. 進行日常程式除錯，並根據市場回饋改善使用者經驗
3. 定期更新開發進度，與團隊匯報產品開發狀（Redmine）
4. 撰寫單元測試以及自動化Acceptance測試（Selenium等）
【其他】
1.有GitHub作品請在履歷附上。 履歷請mail至hr@bonio.com.tw
----------
職稱：Senior FrontEnd工程師
【技能要求】
1.必備：
a. 有一年以上撰寫Javascript的經驗，有解讀開源專案程式碼的能力
b. 熟悉git操作以及有與其他開發者、設計師和產品經理共事的經驗
c. 熟悉Javascript ES6語法，並且有React和Redux的實作經驗
2.加分：
a. 有過帶領開發團隊的經驗（Scrum尤佳）
b. 有過後端（e.g. Node.js）以及Real Time App的開發經驗
c. 有過導入前端自動化工具（e.g. Webpack）以及測試工具（e.g. Mocha、
Enzyme、Nightwatch）的經驗
【工作內容】
1. 與產品經理和設計師溝通，進行雲端產品開發
2. 進行日常程式除錯，並根據市場回饋改善使用者經驗
3. 定期更新開發進度，與團隊匯報產品開發狀（Redmine）
4. 撰寫單元測試以及自動化Acceptance測試（Selenium等）
【其他】
1.有GitHub作品請在履歷附上。履歷請mail至hr@bonio.com.tw
現在學習知識的渠道越來越多，無論對於零基礎或是有經驗的工程師，想要持續成長應該看書還是看影片來的更有效率呢？
主要會和你分享我過去從新手到資深的過程中，如何持續保持進步及學習的經驗
也許這個經驗可以幫助到你，也歡迎留言和我分享你的看法
相信彼此分享不同的學習見解，能讓對於想要更精進自己程式開發功力的人有很大的幫助
===章節===
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
#寫程式 #前端 #後端
[ASP.NET Core] Unit Test 單元測試 - NUnit動手做 ... Learn Unit Testing in C# with NUnit - Tutorial for Beginners. Elias Fofanov. ... <看更多>
【 C# 】【C Sharp】 單元測試 Unit Test (Mock) mock 的使用方法How to use mock method #c ##c sharp#programming #program#unit test#ms ... ... <看更多>
單元測試c# 在 [討論] 多少公司有執行單元測試分享- 看板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
... <看更多>