一、詳解TDD 1.1、TDD概念 ：Test Drived Develop 測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種方法論。TDD的原理是在開發功能代碼之前，編寫單元測試用例代碼，測試代碼決定先編寫什麼產品代碼。TDD雖是敏捷方法的核心實踐，但不只是適用於XP，同樣可以適用於其他開發 ...
一、詳解TDD
1.1、TDD概念 ：Test Drived Develop
測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種方法論。TDD的原理是在開發功能代碼之前，編寫單元測試用例代碼，測試代碼決定先編寫什麼產品代碼。TDD雖是敏捷方法的核心實踐，但不只是適用於XP，同樣可以適用於其他開發方法和過程
TDD的基本思路就是通過測試來推動整個開發的進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過成。
TDD的重要目的不是僅僅測試軟體，測試工作保證代碼質量只是其中一部分，而且是開發過程中幫助客戶和程式員去除模棱兩可的需求。TDD首先考慮使用需求（對象、介面、功能、過程、等）
1.2 測試驅動開發的優缺點
TDD:測試驅動開發的優點：
再任意一個開發節點都可以拿出一個可以使用，含少量的BUG 並具有一定的功能能夠發佈的產品。
TDD：測試驅動開發的缺點：
缺點：增加了代碼工作量。測試代碼幾乎是系統代碼的兩倍或更多，但是同時節省了程式調試的時間以及挑錯的時間。
TDD=TFD+Refactoring 第一次測試開發加上重構
TDD:Test First Development 首次測試開發
1.3、TDD原則
1.獨立測試：不同代碼的測試應該相互獨立，一個類對應一個測試類（對於C代碼或C++全局函數，則一個文件對應一個測試文件），一個函數對應一個測試函數用例也應該各自獨立，每個用例不能使用其他用例的結果數據，結果也不能依賴於例執行順序。一個角色開發過程中包含多種工作，（編寫測試代碼、編寫產品代碼、代碼重構 等。做不同工作的時候，應專註於當前要做的事情，不考慮其他，比如測試的時候就做測試）
2.測試列表：代碼的功能點很多，不可能是所有的需求都是很明確的，而是陸陸續續的出現新的需求，在進行的任何階段時想添加功能時，應把相關的功能點 添加到測試列表中，在繼續改階段的工作，以避免疏漏。
3.測試驅動：及利用測試來驅動開發，是TDD的核心。要實現某個功能，要編寫某個類或某個函數，應該先編寫測試代碼，明確這個類、這個函數如何使用，如何測試，然後對其進行設計、編碼。
4.先寫斷言：編寫測試代碼時，應該首先編寫判斷代碼功能的斷言語句，然後編寫必要的輔助語句。
能應該比較單純，每個類、每個函數、只做自己的事情，不摻雜然和功能。
6.及時重構：對結構不合理，重覆等不好的代碼，在測試通過後，應及時進行重構。
7.小步前進：軟體開發是複雜性非常高的工作，小步前進是降低複雜性的好辦法。
1.4、TDD總結
測試驅動開發：既可以測試框架的性能、也可以測出業務的合理性，也可以測試出代碼的問題、雖然開發時間會延後、但是可以提高客戶的滿意度，上線後系統比較穩定。
一個軟體的產出，需要具有詳細的設計：從開始的競標，到立項到設計，開發，交付任何一個環節都不可缺少。
舉例描述：
某公司競標後拿下了這樣一個工程，在兩座山之間建造一座大橋，產品經理把業務具體分析過後交給了公司的設計師（架構師）設計師根據客戶對產品的質量、美觀、使用性、進行架構設計：產出物如下圖：
架構師設計出有幾個橋墩沉重力度，橋面寬度高度，形狀。。。等。
這樣整體架構就出現了，高級工程師根據架構師的架構進行小的設計比如說用什麼樣的材料怎麼做橋於橋之間的關聯等，（在開發來說就是用什麼介面，介面怎麼制定，怎麼保證安全性）剩下的就交給中級工程師了，等到開發完後進行測試。
上面簡單的描述是一般產品的產出流程，但是一般的流程去做這樣一個特殊的工程顯然不夠的，比如說怎麼知道這個框架是否安全，現在的說服力一般都體現在數字和具體的有說服力的案例上面，但是沒有案例的話，就需要我們隊框架進行測試了，在這個沒有真正做施工之前，框架設計出之後進行的測試，大家就可以理解成TDD測試了，這時候的TDD很顯然偏向於架構的設計。再往小點的方面來說比如測試介面的時候，其實也是設計介面，TDD偏向於設計，而不是很多人認為的測試。
利用TDD 測試驅動 舉一個例子：
業務場景：用戶下訂單，訂單類型“普通訂單、批量訂單、個人訂單” 判斷用戶是是否具有下此類訂單的許可權。
如果所根據這個業務讓咱們設計一下咱們肯定都沒有問題：
資料庫創建腳本
CREATE TABLE OederTable --訂單表 ( ID INT PRIMARY KEY IDENTITY (1,1), -- ID OredrNo varchar(100), --訂單編號 OrderTypeNo varchar(100), --訂單類型編號 CreateBy varchar(200)--創建人 ) CREATE TABLE UserRights --用戶許可權表 ( OrderTypeNo varchar(100),--訂單類型編號 UserID INT --用戶ID ) CREATE TABLE UserTable --用戶表 ( ID INT PRIMARY KEY IDENTITY (1,1), --ID UserName varchar(100), --用戶名 UserPwd varchar(200) --用戶密碼 ) CREATE TABLE TypeTable --訂單類型表 ( OrderTypeNo varchar(100),--訂單類型編號 OrderTypeName varchar(100)--訂單類型名稱 )View Code
填充數據
實現測試業務流程代碼具體如下：
代碼中映射了四個實體類，一個訂單操作類。
訂單操作類具體代碼如下（代碼中並沒有具體實現主要以意會為主（~o~））
//測試代碼 public void TestMethod1() { OrderOperation OrderOperation = new OrderOperation(); OederTable Oeder = new OederTable(); Oeder.OredrNo = "100"; Oeder.OrderTypeNo = "1"; //普通訂單許可權 Oeder.CreateBy = "admin"; //1.驗證用戶是否存在 //2.驗證用戶是否是否具有下訂單的許可權 //3.保存入庫 /************假設用戶表為空時咱們已經通過用戶名密碼查詢過並且存在該用戶*************/ UserTable user = new UserTable(); if (user != null) { //通過UserID查詢許可權是否有下普通訂單的許可權 Oeder.OrderTypeNo = "1"; 普通訂單許可權 UserRights Rights = new UserRights(); if (Rights != null) { //添加入庫 OrderOperation.add(Oeder); } } }View Code
其實不管用任何辦法，只要結果符合描述就行，HARD Code 也是一個很好的方法，我們現在關註點應該放在業務流程的正確性，數據從哪裡來不重要。
如果添加成功最好有一個返回值能體業務的正確性，比如添加成功後返回“OK”
以上描述有部分來自於互聯網：
