(這是在 51testing 論壇上發的帖子，竟然沒乙個人回。不管它，貼在這。)
單元測試有三個方面的作用：
1、測試**行為；
2、改進**設計；
3、作為文件。
其中第一點是單元測試的直接目的。很多人認為只要有了足夠的單元測試，就能夠保證**的高質量。但問題是很多**難於寫單元測 試，比如 jsp 和 servlet，struts 1.x 的設計也對單元測試不友好。我們需要借助其他的包或者一些手段來對它們進行單元測試。這就自然的引出了單元測試的第二個作用：改進**設計。
**設計的改進帶來的好處不僅僅體現在單元測試方面。有了好的設計，一旦需求有變更，開發人員也能更加輕鬆的實現，而且 bug 更少。這也是很多專案管理人員對單元測試青睞有加的原因。但是從很多實踐來看，能夠最大發揮這個作用的只有測試驅動開發（test-driven development）。想想看，如果單元測試不能對設計階段施加影響，就談不上對設計的改進；而設計階段產生的是文件而不是**，自然沒有單元測試。這個矛盾使很多專案的單元測試無法發揮應有的效果。而測試驅動開發將測試作為設計的一部分，在經過粗略的構思之後，提筆就寫測試，然後寫**，通過不停的完善測試，最終形成乙個能夠流暢執行單元測試的系統。這個系統不但有足夠的單元測試保證其行為，而且也是設計良好的。
我們當前許多專案中，設計人員和開發人員各司其職，基本上互不通氣；單元測試是開發人員的事情，開發人員對於改進設計缺乏主動性，甚至是被禁止的。這使得 單元測試陷於兩難境地：一方面糟糕的設計使得寫單元測試比寫**本身還難，另一方面單元測試無法改變糟糕的設計。單元測試成了吃力不討好的東西。而管理者 仍認為**質量不佳是單元測試沒有「到位」，於是再加上一堆的文件試圖將單元測試「規範化」，單元測試更加成了乙個累贅。
這不是單元測試本身的責任，這都是對單元測試的誤解造成的。只要單元測試不能對設計施加有效影響，單元測試就只能陷於這種被動的境地。
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...
我討厭單元測試 滕振宇談如何進行單元測試
說起單元測試的好處相信大家都能列舉出不少，可是很多時候，開發人員面對自己產品的 想寫單元測試卻無從下手，久而久之，便會有人大喊 我討厭單元測試。資深敏捷諮詢師騰振宇 daniel teng 在gtug topgeek開發工程管理沙龍就以此為題，結合最近的乙個專案，和大家分享了他對單元測試的一些看法。...