1樓：小西
一般的軟體工程都會強調ut的重要性，但是在web業務開發中，往往是前後端和db一起完成整個功能。單獨測試其中乙個方面，往往會帶來過高的mock成本。所以整合測試往往更合適。
此外，因為業務變動的非常厲害，乙個預期穩定的業務邏輯往往會做劇烈調整，或者直接廢棄。這進一步造成-ut價效比極差。在這種環境下，TDD就像做夢一般。
加粗部分你可以多閱讀幾次。如果還是覺得沒毛病，那麼我建議你先了解一下什麼是單元測試。
還有，如果業務變動非常厲害，我覺得更必須得有單元測試。
不過話說回來，世界上本沒有單元測試，甚至任何測試。但是寫測試的人多了，越來越多的人感受到了測試帶來的快感，所以才會有人不遺餘力的去考慮如何寫測試，什麼情況下用哪種方式去測試，某個測試方案可以解決什麼樣的問題，才會有單元測試，整合測試，介面測試，契約測試，系統整合後的測試，效能測試壓力測試，甚至對於一些文件也有專門測試等等，每一種測試都是要解決一些或者一類問題。
同時使用哪些測試框架或者方案，也得考慮到專案的成本。
最後還是很疑惑，你認為的單元測試是什麼樣的？ 為什麼mock成本會比較高呢？特別是現在測試框架這麼多的情況下，建議多了解和學習一些測試框架，同時也要多學習如何拆分業務模組，然後回過頭再看就可能有別的感觸了。
2樓：
單元測試就單元測試嘛，寫個 UT 我還想了一下是什麼。
Web 業務開發中單元測試當然是起作用的。mock 成本確實高，但這個成本高僅限於你從單個開發者/測試者的角度看。從整個專案的角度看，大量自動化測試帶來的人力成本削減是顯著的，而這僅僅是顯性成本。
大量單元測試還能帶來隱性成本削減，也就是 @塵猿未盡 提到的強制解耦。對軟體工程來說，一般情況下低耦合都比高耦合要好，而單元測試是一種有額外收益並且成本很低的解耦方案。
需求的變更帶來單元測試的劇烈變化很正常，這種情況的重新開發成本應該被視為正常開發成本的一部分。如果單元測試成本實在太大，要麼是商業決策的責任（意味著業務方向的劇烈變更），要麼是架構的責任（耦合太高，顆粒度太大，可重用元件/測試太少），而幾乎不會是單元測試這個方法本身的責任。
總的來說，樓主你要意識到：單元測試其實不是為程式設計師服務的，而是為架構師和公司組織服務的。它是實現「使程式設計師成為可替換部件」這個管理目標的重要方法，而這個管理目標，是現代科技公司降低「公司與員工」耦合的需求 —— 低耦合帶來低替換成本，無論對於技術還是商業，都是一樣的。
3樓：蒼孫
UT覆蓋率不用太高，程式適當做好分層。業務頻繁變更的部分的確沒時間做UT，但是資料層，公共介面，公共函式，類，可以加強UT覆蓋。
docker在web開發中得使用流程是怎樣的？
糟糕說 docker的容器是以映象來建立的，映象是不是乙個類似作業系統的環境？是的。如果把容器 docker 跟虛擬機器對比，docker的執行時等價於虛擬機器執行時，docker映象等價於虛擬機器映象。兩者底層實現技術不同，docker基於linux系統本身的機制 cgroup,namespace...
在web開發中，資料庫事務（不管是自己實現的事務還是利用資料庫本身的事務）到底有多重要？
郭凜 不同意 莊表偉的說法，例如像銀行結算，企業ERP這種業務對事務的需求就遠超過了對效能的需求，保證最終一致性是不夠的。而大多數網際網路應用則無所謂，發一條微博多幾個少幾個人看到其實無所謂 所以最重要的還是需求 蘿蔔白菜各有所愛 有的團隊嚴格要求使用，有的不支援也不反對，有的反對使用 只要控制好資...
web開發中前端拼模版和後端拼模版的區別？
itlr 前端拼模板可以直接DOM化，更靈活 var tmpl template for item in items compile var items tmpl.render data 直接開始DOM操作 items.find li click function e 後端不可以。你希望顯示邏輯緊湊...