你做的項目中，通常單元測試（Unit test）佔用時間的比例是多少？

01-08

如果條件允許的話，我都是盡量不寫main函數，不做GUI，所有的代碼都用unit test來運行。我也不喜歡做mock，需要資料庫的話就寫個SQL腳本讓他可以在空的資料庫上生成一些我要的單元測試的數據，然後我的程序就真的連接到這上面跑。需要C/S就把兩個測試進程（而非產品）都跑在同一台機器裡面。如果你覺得很難做到，那多半是因為你的代碼依賴了太多系統里的全局狀態，導致你無法輕易地執行它。

等到這些業務邏輯都搞定了，最後data binding上去，加上UI再跑code coverage確保高於90%。這樣UI不用怎麼測試，幾乎不會有錯，整個項目也做好了。

當然並不是所有的老闆都會讓你這麼干，也不是所有的人都有辦法做到這一點。實際上行動起來總是要有各種妥協。說來這個90%的標準其實是我若干年前在Visual Studio實習的時候，老闆要求的。我覺得很好。

百分之十到二十，覆蓋率80到90吧；程序設計的時候已經考慮了可測性。所以寫UT很容易

養成不依賴mock framework的好習慣也很重要，嗯。

30%對日項目

幾乎可以忽略不計：我們進度太緊張了，不可能有時間給所有重要的模塊做單元測試，不過還是給核心功能做了單元測試，時間佔1%吧。。。

我司要轉TDD的感覺。有專門的測試寫Unit Test。最近頻繁更新Web Api, 新寫的Api 自己搞搞Integration Test比較方便。只Mock database就好，中間的數據都不搞。我只需要了解更新了代碼，其他相關API沒有問題即可，真正好且不應付的Unit test 工作量太大，交給專職測試比較好。

佔據30%以上時間。這非常划算，因為：

「單元測試」是指你對你的代碼進行細粒度的模塊隔離的測試。即使你不寫自動化測試，你仍然要為此付出成本：手動刷新頁面，手動一次次的運行程序，來驗證你的代碼是不是正確。

當你的項目逐漸複雜，這樣做的成本就越來越高。項目最初的時候，也許編譯、執行來做人工單元測試要比自動單元測試來的快得多，但是這很大程度取決於程序員對測試工具的熟練程度。熟練掌握測試工具的程序員，可以忽略「麻煩」的感覺。

而這只是自動化單元測試的其中一個作用：協助開發。至於另一個作用：回歸測試，手工測試就沒辦法，而黑盒測試員測試，成本當然是顯著高於自動化單元測試。

因此一個項目越大，就越有必要提高測試覆蓋率。這一點直接同時影響著迭代開發和回歸測試兩大塊，從而很大程度上影響著一個大項目前進的速度。

咱們假遊戲行業的程序員是從來不寫單元測試的，測試全靠黑盒

誠實的說，基本不做，主要黑盒測試...

理論上我們要求寫測試和寫實現的時間是比是至少1：1。當然實際上沒那麼高。（PS我們是金融公司，曾經出過弄丟客戶幾十萬美金的bug，不知道被交易到哪裡去了，而且好像到現在都不知道…公司自掏腰包賠了客戶）

兩個星期左右的項目，最後花一到兩天時間做核心邏輯的單元測試

一般大概15到20吧，單元測試是很重要的，保證代碼質量，覆蓋率的話大概80到85左右吧，要做到95以上還需要花更多的時間，當然我說的平均水平啊，有一些測試同學不好測試的地方可能寫測試德時間就會多一點，畢竟有些邏輯測試同學測不到，只能開發自測，個人情況

無

長期來看，幾乎忽略不計

老闆不要求，看心情，有時候會對局部功能寫個測試。

超級大軟體做個測試也是不容易，基本上都是dll寫完直接放到整個軟體裡面去調試找bug。