之前寫了關於nunit和justmock的介紹，我們都知道這只是單元測試的工具，最終還得回歸理論。
（廢話想說一些：如果我們聽到乙個陌生的概念，不去追問它是什麼，它有什麼用？直接進行任務去完成這個概念描述的事，那麼，我們可能很難理解我們為什麼要這麼做，也可能做不好。）
與其它**隔離：單元測試**不影響其它**，需建立獨立專案檔案；
與其他開發人員隔離：每個開發人員編寫的單元測試不互相干擾；
有針對性：單元測試是針對乙個特定的工作單元編寫的；
可重複：單元測試可以重複執行，並且保證每次結果都正確；
可**：能夠確定方法輸入x，將返回y。
大部分公司即使要求編寫單元測試也是先寫業務**，再編寫測試**去測試。由於開發人員水平不齊，業務**不能保證質量，可能導致難以測試。我收集了經常遇到一些阻礙測試的問題。
當然還有很多情況阻止著我們編寫單元測試。解決的辦法遵循三個點：
一是編寫業務**嚴格執行單一職責原則；
二是面向介面程式設計，使用依賴注入；
三是利用工具模擬外部資源。
== 另外一點 ==
我們總將一些靜態資源封裝成靜態類，當這些類也參與業務邏輯，那麼就會影響編寫單元測試。比如：架構組將操作redis的庫編寫成靜態類，如果執行測試將會影響redis資料。令人頭疼的是，基本上所有的免費框架都不支援mock靜態類。目前，我採取的方法是使用justmock的付費功能。經驗有限，希望發到部落格有大神指出解決方案。
嚴格根據tdd思維，遵循solid原則 開發能保證**質量
tdd 確保了**與業務需求高度一致性
tdd 鼓勵建立更簡單、針對性更強的庫和api
tdd 要落實測試單元，需要鼓勵與業務方持續溝通
tdd 有助於清除無用**。無用**實際上維護成本非常高
tdd 提供了內建的回歸測試。再次執行測試**可檢查修改乙個方法邏輯會不會影響到其它現有功能
tdd 阻止遞迴錯誤。每個測試都針對系統缺陷，那麼，同樣的錯誤不會再次發生
tdd 開發應用程式的系統是開放的、可擴充套件的、靈活的系統。
以上都是廢話，我還沒完整體驗過真正的tdd開發線上系統。理解測試驅動開發的理念，能讓我們編寫更漂亮的**倒是真的。
tdd 的三個階段：
紅燈階段
編寫貼合需求的測試**，盡量保證覆蓋需求每個點。
綠燈階段
編寫適當**，使測試通過。合理命名乙個方法名，然後簡短完成方法。可能乙個範湖bool型的方法只寫乙個返回**。
重構階段
這個階段是真正完成業務邏輯的階段。因為我們編寫的測試**已經完整滿足業務需要，所以，我們只需要根據測試**，編寫完業務**，再通過測試即可。
完成一項工程，不要期待只走一遍流程就完成了，寫**從來沒有容易的事，很多時候，我們都需要反反覆覆修改，不僅僅是需求更改，也為了讓我們「以前」寫過的**更整潔。
我目前還是覺得，很艱難能堅持tdd模式開發，很難讓你的團隊的夥伴都轉變思維，從測試**開始。但不妨礙我們去體會tdd，我們帶著測試的思維去寫業務**，時刻都想著，我這樣設計會不會很難測試。如果我們的**讓我們很難測試，我相信他大概率也不是好的**。
以上，我的理解。學無止境，望高人指點一二，向大佬學習。
測試驅動開發 JUNIT 單元測試類
單元測試需要構造資料 而且會考慮到事務的回滾等等問題,測試 的構建如下 路徑問題 1 在 src 目錄下 runwith org.springframework.test.context.junit4.springjunit4classrunner.class contextconfiguratio...
測試驅動開發之基礎 單元測試
學習測試驅動開發之前，應當正確理解一下單元測試的概念，學習單元測試之後可以清楚的知道所謂的單元為單一職責的乙個方法即乙個方法只做一件事情，這也符合物件導向的單一職責的原則。因此單元測試的概念可以籠統的理解為 針對乙個工作單元設計的測試。單元測試有各種不同的編寫方式，但所有單元測試有些共同的特徵 1....
測試驅動開發中的測試，單元測試中的測試的區別
測試驅動開發和單元測試不是乙個東西，但是今天好像有點暈。覺得兩個又像乙個東西，所以，寫了點東西希望大家指教。測試驅動開發中的測試和單元測試中的測試的區別 時機不同 測試驅動開發中的測試，是在寫 之前。單元測試中的測試，實在寫 之後。目的不同 測試驅動開發中的測試，是為了開發 和重構 單元測試中的測試...