1樓：
咖哩同事們開發乙個基礎服務，單元測試覆蓋很漂亮，各種安全掃瞄都通過，可還是超級不穩定，三天兩頭崩或者區域性功能不能用，錯誤提示張冠李戴，都甚至不好意思再去挑他們許可權控制設計上的紕漏了。
2樓：
賣東西需要提供（法定之外的）保修嗎？那要看保修對買家購買選擇的影響力有多大啊。
買東西需要選擇買有保修的嗎？那要看這個東西有多大的可能性會壞以及壞了的情況會有多糟糕。
測試也是同樣的道理，說不清楚寫測試的成本有多高以及不寫測試的後果有多壞，那是無法通過對比得到答案的。一切關於測試有多好的高談闊論，都是空對空。
具體到某一家公司，寫不寫測試可能是由文化決定的，這個文化可能是由這家公司所在的業務領域經過長時間積累而形成。如果一家公司所在的領域犯錯成本很高，一番自然淘汰後，省下來的都是通過測試以及其它手段保證質量的公司。但如果一家公司所在的領域犯錯成本很低，那自然是「move fast and break things」了。
在這方面我可以輕易地使用 Facebook 作為例子，反對 @程墨Morgan 和 @vczh 的答案。Facebook 就是長期運作在乙個犯錯成本很低的領域，出了什麼問題就道個歉啊，然後說自己真心想做好事的。就算是國會傳喚，也是同樣的套路，道歉了事。
監管部門要罰款？罰金數額只是 Facebook 現金流的一小部分，沒關係。換乙個醫療或金融行業這樣做試試看？這些行業在美國的監管如此之強，隨便犯個小錯就可能罰到你破產。
題主去 ThoughtWorks 面試因為不重視測試而被鄙視了，但不能因此就說越是大型和正規的公司就越重視測試。ThoughtWorks 是做諮詢的，客戶企業可能從事受到嚴格法律監管的領域，要求高也是可以理解的，但 Facebook 顯然是個反例。
Antifragile: Things That Gain from Disorder
如果你的軟體是脆弱的，也就是出現隨機波動的負面影響遠大於正面影響，那你就乖乖寫測試吧，你的目標是讓你的軟體變得健壯。
發明新產品必須是乙個反脆弱的過程，也就是說軟體波動起來正面影響要遠大於負面影響，這時候還寫什麼測試，趕緊讓軟體在有限的時間內嘗試盡可能多的不同的改動，看看哪乙個能成功爆發。
為什麼這是個反脆弱的過程呢？因為如果軟體的任何乙個嘗試都不成功，你的損失是有限的，你原本沒有乙個成功的軟體，現在還是沒有乙個成功的軟體，時間損耗是可控的。但如果任何乙個嘗試成功了，那都可能是指數級爆發，那是不封頂的。
3樓：jiaao yu
單元測試就是乙個已經經過校準的精密工具機，你當然可以說純手工的打造乙個零件，但當系統足夠複雜的時候，沒有校準，你的東西會組裝不到一起去。
出了問題的時候，你不知道是因為哪個零件不準確造成的。唯一的辦法就是挨個檢查。
但系統足夠小，沒有模組化，單元測試你是不需要的，因為系統本身就可以看作是乙個單元測試。
在 Web 業務開發中，單元測試真能起到作用嗎？
小西 一般的軟體工程都會強調ut的重要性，但是在web業務開發中，往往是前後端和db一起完成整個功能。單獨測試其中乙個方面，往往會帶來過高的mock成本。所以整合測試往往更合適。此外，因為業務變動的非常厲害，乙個預期穩定的業務邏輯往往會做劇烈調整，或者直接廢棄。這進一步造成 ut價效比極差。在這種環...
如何單獨編譯chrome單元測試？
你我 首先根據你給的這個鏈結，我們可以知道這是個unit test，chromium的C unit test是所謂的GTest。然後我們就去http cs.chromium.org 搜這個檔案的名字，看看它在哪個gn target，發現這個東西是net unittest的一部分。那麼假設你已經知道怎...
如何對vue js單檔案（ vue）進行單元測試？
HDDDDD 如果你需要一些工具可以看看這篇總結文章 5個用於測試Vue.js應用程式的有用工具和庫我自己用 React 比較多，測試用的 jest，如果用的 React 可以看看這篇文章 前端測試 1 庫 框架 概念 Jest enzyme sinon nock 非同步資料API盡量單獨提取檔案，...