FAQ-單元測試相比手動調試有什麼優勢？

01-08

我發現做單元測試所付出的時間遠比手動調試要高很多,比如在JS中利用CONSOLE.LOG和打斷點就能很好的滿足測試需求.

單元測試可以放在source control裡面，有人checkin立刻執行，執行掛了直接revert。你手動調試能這樣嗎，坐在那整天刷新看看人家有沒有checkin……？

你一旦發現了個bug，就可以先把它表達成一個單元測試，然後通過debug這個單元測試來debug你的程序。以後再也不會一不小心重新引入這個bug了。你手動調試的話真的會有那麼多責任心把幾十年前CTO年輕的時候犯的錯誤都一個一個拿出來試？特別是你剛剛重構完一坨屎一樣的代碼的時候？

團隊里的人是懶惰的，不要挑戰團隊的人性。

首先，題主把 Testing 與 Debugging 兩個概念搞混了，測試與調試不是一回事（雖然中文只差一個字），兩者的目的和用途均不同。

我發現做單元測試所付出的時間遠比手動調試要高很多,比如在JS中利用CONSOLE.LOG和打斷點就能很好的滿足測試需求.

不過，這個問題還是很有意思，有價值。後面我還會分析到，比如：全面的自動單元測試可以幫助你更快、更早地發現錯誤，從而減少手工調試的必要與麻煩；兩者是相互促進，而非彼此取代的關係。

測試

Testing 通常譯作「測試」、「測驗」或「檢驗」等。

單元測試主要是驗證一個軟體單元或某個模塊（如一個對象的某個方法，或某一個方面的職能）是否符合設計要求能正常工作。驗證一個方法的輸入與輸出結果，可能存在多種組合 n 種情況，所以編寫 UT 往往是要花時間的，然而執行 UT 往往又是很快的，一般幾千個測試只要幾分鐘時間，因為普遍採用的是自動單元測試（AUT）工具。

自 xUnit 系列工具誕生以來，有手動（執行）單元測試的嗎？還沒聽說過。

調試

再來說說手動調試（Manual debugging）。

在軟體的使用和測試過程當中，哪裡發現了問題，有 bugs，就需要進行調試（Debugging）或糾錯，去除軟體中的差錯，我稱之為「掐蟲」。

利用 Debugger 打斷點、單步跟蹤，或用 Logger 輸出調試日誌，是日常調試時常用的一些手段。

然而，有用 Debugger 或 Logger 來做自動單元測試的嗎？也沒聽說過。

所以，說「手動調試效率比單元測試高很多」，或者「打日誌、打斷點能很好地滿足測試需求」，這很滑稽。

測調集成

也可叫「測調聯合」。

全面的單元測驗能取代、取消手工調試嗎？不能。

手工調試能全面取代單元測驗嗎？也不能。

關於 Testing 與 Debugging (by tracing, or logging) 在 Web/JavaScript 開發中是如何和諧共存、相得益彰的，有一個很好的例子 —— 我開發的 Web 測調集成工具 Wt (http://zhangxun.com/?wt)：

左邊是 JS 單測的所有 test cases，而反映即時運行結果的調試日誌 JS Log 在右邊。。。。

單元測試的存在不僅僅是為了發現問題，debug是可以找出問題，但是只適合小作坊式的代碼開發或者是獨立開發者。它是無法發現別人broke了你的代碼的自從有了單元測試，

1. 不再懼怕重構

2.合併代碼之後跑一跑，有問題一眼就看出

3. 有bug的時候針對bug寫一個單元測試，更自信

4. 和CI工具集成起來，保證代碼一直為穩定狀態

5. 人工測試很難測到的一些極端情況，比如閾值臨界點，跨時區跨年分計算等，通過mock輕鬆解決

不寫單元測試就提交代碼是對其他程序員耍流氓的自負行為

調試僅僅是程序診斷手段。而自動測試是集成管理、缺陷管理、輔助設計、功能示例等功用於一身。

自動，一勞永逸。

單元測試或者其他測試用例最大的作用不是可以去掉BUG，或者類似的一勞永逸的目的，而是讓試圖重構你代碼的人（包括你自己）更有信心與底氣，讓你的代碼本身可以迭代。代碼具備了迭代能力，就會超好的方向前進。

所有自動化測試的一個特點就是一開始需要不少的投入，但一旦克服平台期，邊際成本是越來越低的。

而手工調試的成本是不會隨著時間明顯下降的，反而隨著項目複雜度有上升的危險。

當你把API公布給別人使用的時候，不需要手把手指導，把測試代碼扔給他就可以了
當你不太明確介面之時，假設自己是調用方，寫點測試代碼，能夠設計出更易用的介面，測試驅動開發
過了幾個月之後，發現以前的代碼有bug，修改好了之後，只需要重新運行一遍測試代碼即可，回歸測試
出現bug之時，測試得最全面的代碼是你最放心的，然後你的關注點會聚焦到很少測試的代碼，而這些往往是bug之源

拿我們團隊內的情況來說，我們有一個項目涉及嵌入式設備開發，裡面還涉及到無線數據傳輸模塊，集成測試會相當麻煩。

我們的測試框架用常見的Gerrit和Jenkins來做，每次commit都會觸發Jenkins來跑單元測試，還會有一些UI自動化。

為啥要單元測試？

可以部署自動化測試，跑完了反饋一個報告，掛了就給Gerrit上個-1/-2不讓merge。
假設一個函數接受若干個位元組，若干個位元組有許多種組合，你手動調試調不知道要調到什麼時候，還會漏掉一些情況。
單元測試也是測試用例管理的好辦法，一個函數五六個測試用例，一個模塊有許多函數要測試。你寫單元測試就省去你再搞一個文件單獨存測試用例了。如果你手動調，你是不是要做個表格出來記錄？
此外，單元測試可以幫助你編寫可被測試的代碼，什麼注入啊，抽象介面啊。其實也是幫助你思考如何構建更好的代碼結構。
優良的單元測試管理可以幫助做回歸測試，防止一些舊的bug在未來的改動中又出現。
現在業內許多公司都推崇的TDD（測試驅動開發），也是需要大量的單元測試。好處也很明顯，能保證你的代碼執行時在業務邏輯上永遠是對的。
看著爽，編譯的時候看命令行刷單元測試，刷刷刷全是"Success"，這感覺多棒。

當然凡事都不能說死，簡單的個人項目你要是不寫單元測試也沒啥。但是若這個項目是一個產品，是要給大量用戶使用的，那麼手動調試就會使軟體質量得不到保障。

其實就算個人開發，勤寫單元測試也是好習慣。對於我來說是開發中必須的一個步驟。

下意識認為樓主是要比較「單元測試」和「手工測試」，結果是坑爹的「手動調試」。。。這是關公戰秦瓊，張飛斗岳飛嗎？

先按我理解的來答：

以上是best practice推薦的測試分布，單元測試佔大部分，集成測試次之，系統/驗收測試再次，最後是手工測試。單元測試的優點：

測試先行，在寫實現代碼前就開始梳理需求和模塊性
零環境配置，在開發機器和CI server中都應該跑出一致的結果
跑得快，多數幾~幾十毫秒一個，一般的項目很快就跑完了
易於執行，寫代碼時不放心怕破壞了已有業務邏輯，可以隨時跑跑看看；提交前可以跑；提交後CI server可以先於其他測試跑單元測試，誰的change搞壞了哪個測試一目了然，趕緊打回重練。因為易於執行，VS中一鍵搞定，所以誰也沒有借口不跑，自然成為團隊流程

手工測試扯皮的事就多了：

測試測出來一個bug，開發的第一反應是「不可能！我機器都重現不出來！你丫沒配對吧！」
即使要求開發在提交前做一些手工測試，因為團隊成員水平、態度不一，水分會很大，你懂的。不認真執行的人多了，久而久之這個流程就廢了。單元測試就是白紙黑字，無可抵賴

至於你理解的「單元測試所付出的時間代價比較大」，不管你是跟手工測試還是手動調試來比。初期的學習曲線和時間成本肯定是有的，但是對團隊開發來說，中期和長期回報巨大。項目規模（代碼，人員）的膨脹在質量上是可控的。而且你看github上好多個人項目還寫單元測試呢，我拿到一個就看測試怎麼寫的，就知道怎麼用這個庫。

你要理解，開發效率的提高往往都和自動化有關，把一個流程自動化意味著：

減少執行時間，可以周期反覆執行
節省人力成本，團隊的聰明才智可以在其他地方閃光
易於執行，更能被團隊接受，減少推行阻力
減少手工出錯的機會

最近在看新版《俠客行》，看到這個問題，突然覺得單元測試有點像俠客島，外面的人都抗拒，島上的人都不想出來，整個一個圍城的反面。

沒玩明白自動化測試之前，很是質疑，玩明白之後，爽得飛起。

單元測試可以無限次被執行

單元測試是很好的文檔

單元測試可以很快地被執行

單元測試可以被任何人和系統執行

單元測試可以快速定位到錯誤代碼

單元測試不會突然被女友喊回家

用例窮盡，回歸測試

據說，在狼長的RD部門還需要12點下班的時候，QA部門是可以做到六點就下班的

跟我說的人大讚QA部門自動化測試做的好，腳本寫的遛

1 單元測試可非常方便的自動化，參考其他答案

2 單元測試可以非常容易構造各種極端場景，而手工測試對於大型軟體中一個小模塊來說很難構造出這些場景。

3 同意 @吳志強的答案，測試代碼也是學習API學習已有程序的非常好的途徑。

單元測試可重用啊,難道你想每次上線前都要手動測試一下,比如第一次上線10個功能,是不是覺得手動測試沒問題.但是迭代3次,每次10個功能,那就是10+2*10+3*10 ,是不是覺得還是可以接受,對比一下真實情況你就知道不可能了.

code永遠是變化的，今天小王寫的code在第二天被小李修改了6次，如果有單元測試覆蓋了小王的業務邏輯，小李每次修改都跑一遍單元測試，可以保證自己的code是可以work的（單元測試保證業務邏輯的正確，提高code的可維護性）。

至於console.log這種，我在寫單元測試的時候，也經常用，主要用來斷點排障，debug用，調試用。

某項目有10萬個測試用例。手工測試的話，15個人需要兩年才能測試完。

所以你說咱們選擇花兩年時間寫一遍單元測試還是每次提交代碼都要花兩年時間去手工測試？

程序員八榮八恥之一：以單元測試為榮，以逐行調試為恥。