手把手教你實戰TDD

1. 前言

領域驅動設計，測驗驅動開發，

我們在《手把手教你落地DDD》一文中介紹了領域驅動設計（DDD）的落地實戰，本文將對測驗驅動開發（TDD）進行探討，主要內容有：TDD基本理解、TDD常見誤區、TDD技術選型，以及案例實戰，希望通過本文，讀者能夠理解掌握TDD并將其應用于實際開發中，

2. TDD基本理解

測驗驅動開發（TDD）是一種軟體開發方法，要求開發者在撰寫代碼之前先撰寫測驗用例，然后撰寫代碼來滿足測驗用例，最后運行測驗用例來驗證代碼是否正確，測驗驅動開發的基本流程如下：

2.1 第一步、撰寫測驗用例

在撰寫代碼之前，先根據需求撰寫測驗用例，測驗用例應該覆寫所有可能的情況，以確保代碼的正確性，

這一步又稱之為“紅燈”，因為沒有實作功能，此時測驗用例執行會失敗，在IDE里面執行時會報錯，報錯為紅色，

2.2 第二步、運行測驗用例

由于沒有撰寫任何代碼來滿足這些測驗用例，因此這些測驗用例將會全部運行失敗，

2.3 第三步、撰寫代碼

撰寫代碼以滿足測驗用例，在這個程序中，我們需要撰寫足夠的代碼使所有的測驗用例通過，

這一步又稱之為“綠燈”，在IDE里面執行成功時是綠色的，非常形象，

2.4 第四步、運行測驗用例

撰寫代碼完成之后，運行測驗用例，確保全部用例都通過，如果有任何一個測驗用例失敗，就需要回到第三步，修改代碼，直至所有的用例都通過，

2.5 第五步、重構代碼

在確保測驗用例全部通過之后，可以對代碼進行重構，例如將重復的代碼抽取成函式或類，消除冗余代碼等，

重構的目的是提高代碼的可讀性、可維護性和可擴展性，重構不改變代碼的功能，只是對代碼進行優化，因此重構之后的代碼必須依舊能通過測驗用例，

2.6 第六步、運行測驗用例

重構之后的代碼，也必須保證通過全部的測驗用例，否則需要修改至用例通過，

3. TDD常見的誤區

3.1 誤區一、單元測驗就是TDD

單元測驗是TDD的基礎，但單元測驗并不等同于TDD，

單元測驗是一種測驗方法，它旨在驗證代碼中的單個組件（例如類或方法）是否按預期作業，

TDD是一種軟體開發方法，它強調在撰寫代碼之前先撰寫測驗用例（即單元測驗用例），并通過不斷運行測驗用例來指導代碼的設計和實作，TDD是基于單元測驗的，TDD的撰寫的測驗用例就是單元測驗用例，

TDD還強調測驗驅動開發程序中的重構階段，在重構階段優化代碼結構和設計，以提高代碼質量和可維護性，單元測驗通常不包括重構階段，因為它們主要關注單元組件的功能性驗證，

3.2 誤區二、誤把集成測驗當成單元測驗

TDD在很多團隊推不起來，甚至連單元測驗都推不起來，歸根到底是大家對TDD和單元測驗的理解有誤區，很多開發者在撰寫測驗用例時，以為自己撰寫的是單元測驗，但實際上寫的卻是集成測驗的用例，原因就在于不理解單元測驗和集成測驗的區別，

單元測驗是指對軟體中的最小可測驗單元進行檢查和驗證的程序，通常是對代碼的單個函式或方法進行測驗，單元測驗的物件是代碼中的最小可測驗單元，通常是一個函式或方法，單元測驗的范圍通常局限于單個函式或方法，只關注該函式或方法對輸入資料的處理和輸出資料的正確性，不涉及到其他函式或方法的影響，也不考慮系統的整體功能，

集成測驗是指將單元測驗通過的模塊組合起來進行測驗，以驗證它們在一起能否正常協作和運行，集成測驗的物件是系統中的組件或模塊，通常是多個已通過單元測驗的模塊組合起來進行測驗，集成測驗可以發現模塊之間的兼容問題、資料一致性問題、系統性能問題等，

在實際開發中，許多開發者只對最頂層的方法寫測驗用例，例如直接對Controller方法撰寫測驗用例，然后啟動容器，讀寫外部資料庫，圖省事一股腦把Controller、Service、Dao全測了， 這實際上寫的是集成測驗的用例，這會造成：

• 測驗用例職責不單一

單元測驗用例職責應該單一，即只是驗證業務代碼的執行邏輯，不確保與外部的集成，集成了外部服務或者中間件的測驗用例，都應視為集成測驗，

• 測驗用例粒度過大

只針對頂層的方法撰寫測驗用例（集成測驗），忽略了許多程序中的public方法，會導致單元測驗覆寫率過低，代碼質量得不到保障，

• 測驗用例執行太慢

由于需要依賴基礎設施（連接資料庫），會導致測驗用例執行得很慢，如果單元測驗不能很快執行完成，開發者往往會失去耐心，不會再繼續投入到單元測驗中，

可以說，執行慢是單元測驗和TDD推不起來的非常大的原因，

結論：單元測驗必須屏蔽基礎設施（外部服務、中間件）的呼叫，且單元測驗僅用于驗證業務邏輯是否按預期執行，

判斷自己寫的用例是否是單元測驗用例，方法很簡單：只需要把開發者電腦的網路關掉，如果能正常在本地執行單元測驗，那么基本寫的就是單元測驗，否則均為集成測驗用例，

2.3 誤區三、專案工期緊別寫單元測驗了

開發者在將代碼提交測驗時，我們往往要求先自測通過才能提測，那么，自測通過的依據是什么？我認為自測通過的依據是開發者撰寫的單元測驗用例運行通過、且覆寫了所有本次開發相關的所有核心方法，

我們在需求排期時，可以將自測的時間考慮進去，為單元測驗爭取足夠的時間，

越早的單元測驗作用越大，我們可以及早發現代碼中的錯誤和缺陷，并及時進行修復，從而提高代碼的可靠性和質量，而不是等到提測之后再修復，此時修復的成本更高，

在專案工期緊迫的情況下，更應該堅持寫單元測驗，這不會影響專案進度，相反，它可以幫助我們提高代碼的質量和可靠性，減少錯誤和缺陷的出現，從而避免了后期因為錯誤導致的額外成本和延誤，

本文介紹了不少提交單元測驗運行速度地方法，讀者可以將之應用到實際專案中，減少單測對開發時間的影響，

2.4 誤區四、代碼完成后再補單元測驗

任何時候寫單元測驗都是值得鼓勵的，都能使我們從單元測驗中受益，

代碼完成后再寫單元測驗的做法會導致問題在開發程序中被忽略，并在后期被發現，從而增加了修復問題的成本和風險，

TDD要求先寫測驗用例再寫代碼，開發人員應該在撰寫代碼前就開始撰寫相應的測驗用例，并在每次修改代碼后運行測驗用例以確保代碼的正確性，

2.5 誤區五、對單元測驗覆寫率的極端要求

有的團隊要求單元測驗覆寫率要100%，有的團隊則對覆寫率沒有要求，

理論上單元測驗應該覆寫所有代碼和所有的邊界條件，在實際中我們還需要考慮投入產出比，

在TDD中，紅燈階段寫的測驗用例，會覆寫所有相關的public 的方法和邊界條件；在重構階段，某些執行邏輯被抽取為private方法，我們要求這些private方法中只執行操作不再進行邊界判斷，因此重構后產生的private方法我們不需要考慮其單元測驗，

2.6 誤區六、單元測驗只需要運行一次

許多開發人員認為，單元測驗只要運行通過，證明自己寫的代碼滿足本次迭代需求就可以了，之后不需要再運行，

實際上，單元測驗的生命周期時和專案代碼相同的，單元測驗不只是運行一次，其影響會持續到專案下線，

每一次上線，都應該全量執行一遍單元測驗，確保從前的測驗用例都能通過，本次需求開發的代碼沒有影響到以前的邏輯，這樣做能避免很多線上的事故，

一些年代久遠的系統，我們對內部邏輯不熟悉時，如何使變更范圍可控？答案就是全量執行單元測驗用例，假如從前的測驗用例執行不通過了，也就意味著我們本次開發影響了線上的邏輯，老系統沒有單元測驗怎么辦？補，幸運的是現在有不少自動生成單元測驗的工具，讀者可以自行研究，

4. TDD技術選型

4.1 單元測驗框架

JUnit和TestNG都是非常優秀的Java單元測驗框架，任選其中一個都可以完整實踐TDD，本文采用JUnit 5，

4.2 模擬物件框架

在單元測驗中，我們常常需要使用Mock進行模擬物件，以便模擬其行為，使得單元測驗可以更容易地撰寫，

Mock框架有很多，例如Mockito、PowerMock等，本文采用Mockito，

4.3 測驗覆寫率

本文采用Jacoco作為測驗覆寫率檢測工具，

Jacoco是一款Java代碼覆寫率工具，它可以幫助開發人員在代碼撰寫程序中監測測驗用例的覆寫情況，以便更好地了解測驗用例的質量和代碼的可靠性，Jacoco可以在代碼執行期間收集覆寫資訊，同時還可以生成報告，以便開發人員能夠更好地了解代碼的測驗覆寫率，

Jacoco還支持在Maven、Gradle等構建工具中使用，開發人員可以通過在pom.xml或build.gradle檔案中添加Jacoco插件來集成，

4.4 測驗報告

測驗報告框架有許多，例如Allure，讀者可自行研究學習，

5. TDD案例實戰

5.1 奇怪的計算器

本案例我們將實作一個奇怪的計算器，通過這個案例完整實踐TDD的幾個步驟，

限于篇幅，Maven pom檔案、測驗報告生成等配置就不貼出來了，請讀者自行到本案例代碼tdd-example/tdd-example-01中查看，

本案例的代碼地址為：

https://github.com/feiniaojin/tdd-example

5.1.1 第一次迭代

奇怪的計算器的需求如下：

輸入：輸入一個int型別的引數
處理邏輯：
	(1)入參大于0，計算其減1的值并回傳；
	(2)入參等于0，直接回傳0；
	(3)入參小于0，計算其加1的值并回傳

接下來采用TDD進行開發，

• 第一步、紅燈

撰寫測驗用例，實作上文的需求，注意有三個邊界條件，要覆寫完整，

public class StrangeCalculatorTest {  
	
	private StrangeCalculator strangeCalculator;  
	  
	  
	@BeforeEach  
	public void setup() {  
		strangeCalculator = new StrangeCalculator();  
	}  
	  
	@Test  
	@DisplayName("入參大于0，將其減1并回傳")  
	public void givenGreaterThan0() {  
		//大于0的入參  
		int input = 1;  
		int expected = 0;  
		//實際計算  
		int result = strangeCalculator.calculate(input);  
		//斷言確認是否減1  
		Assertions.assertEquals(expected, result);  
	}  
	  
	@Test  
	@DisplayName("入參小于0，將其加1并回傳")  
	public void givenLessThan0() {  
		//小于0的入參  
		int input = -1;  
		int expected = 0;  
		//實際計算  
		int result = strangeCalculator.calculate(input);  
		//斷言確認是否減1  
		Assertions.assertEquals(expected, result);  
	}  
	  
	@Test  
	@DisplayName("入參等于0，直接回傳")  
	public void givenEquals0() {  
		//等于0的入參  
		int input = 0;  
		int expected = 0;  
		  
		//實際計算  
		int result = strangeCalculator.calculate(input);  
		//斷言確認是否等于0  
		Assertions.assertEquals(expected, result);  
	}  
}

此時StrangeCalculator類和calculate方法還沒有創建，會IDE報紅色提醒是正常的，

創建StrangeCalculator類和calculate方法，注意此時未實作業務邏輯，應當使測驗用例不能通過，在此拋出一個UnsupportedOperationException例外，

public class StrangeCalculator {

	public int calculate(int input) {  
		//此時未實作業務邏輯，因此拋一個不支持操作的例外，以便使測驗用例不通過
		throw new UnsupportedOperationException();  
	}  
}

運行所有的單元測驗：

此時報告測驗不通過：

• 第二步、綠燈

首先實作givenGreaterThan0這個測驗用例對應的邏輯：

public class StrangeCalculator {  
	public int calculate(int input) {  
		//大于0的邏輯  
		if (input > 0) {  
			return input - 1;  
		}  
		//未實作的邊界依舊拋出UnsupportedOperationException例外
		throw new UnsupportedOperationException();  
	}  
}

注意，我們目前只實作了input>0的邊界條件，其他的條件我們應該繼續拋出例外，以便使其不通過，

運行單元測驗，此時有3個測驗用例，其中只有兩個出錯了，

繼續實作givenLessThan0用例對應的邏輯：

public class StrangeCalculator {  
	public int calculate(int input) {  

		if (input > 0) {  
			//大于0的邏輯  
			return input - 1;  
		} else if (input < 0) {
			//小于0的邏輯  
			return input + 1;  
		}  
		//未實作的邊界依舊拋出UnsupportedOperationException例外
		throw new UnsupportedOperationException();  
	}  
}

運行單元測驗，此時有3個測驗用例，其中有1個出錯：

繼續實作givenEquals0用例對應的邏輯：

public class StrangeCalculator {  
	public int calculate(int input) {  
		//大于0的邏輯  
		if (input > 0) {  
			return input - 1;  
		} else if (input < 0) {  
			return input + 1;  
		} else {  
			return 0;  
		}  
	}  
}

運行單元測驗：此時3個測驗用例都通過了：

此時，打開Jacoco的測驗覆寫率報告（tdd-example的pom.xml檔案中將報告生成的位置配置為target/jacoco-report），打開index.html，

可以看到，calculate所有的邊界條件都覆寫到了，

• 第三步、重構

本案例calculate中只有簡單的計算，在實際開發中，我們進行重構時，可以將具體的業務操作抽取為private方法，例如：

public class StrangeCalculator { 

	public int calculate(int input) {  
		//大于0的邏輯  
		if (input > 0) {  
			return doGivenGreaterThan0(input);  
		} else if (input < 0) {  
			return doGivenLessThan0(input);  
		} else {  
			return doGivenEquals0(input);  
		}  
	}  
	
	private int doGivenEquals0(int input) {  
		return 0;  
	}  
	
	private int doGivenLessThan0(int input) {  
		return input + 1;  
	}  
	
	private int doGivenGreaterThan0(int input) {  
		return input - 1;  
	}  
}

再次執行單元測驗，測驗通過，

查看Jacoco覆寫率的報告，可以看到每個邊界條件都被覆寫到，

5.1.2 第二次迭代

奇怪的計算器第二次迭代的需求如下：

（1）針對大于0且小于100的input，不再計算其減1的值，而是計算其平方值；

第二個版本的需求對上一個迭代的邊界條件做了調整，我們需要先根據本次迭代，整理出新的、完整的邊界條件：

（1）針對大于0且小于100的input，計算其平方值；
（2）針對大于等于100的input，計算其減去1的值；
（3）針對小于0的input,計算其加1的值；
（4）針對等于0的input,回傳0

此時，之前的測驗用例的入參有可能已經不滿足新的邊界了，但是我們暫時先不管它，繼續TDD的“紅燈-綠燈-重構”的流程，

• 第一步，紅燈

在StrangeCalculatorTest中撰寫新的單元測驗用例，用來覆寫本次的兩個邊界條件，

@Test  
@DisplayName("入參大于0且小于100，計算其平方")  
public void givenGreaterThan0AndLessThan100() {  

	int input = 3;  
	int expected = 9;  
	//實際計算  
	int result = strangeCalculator.calculate(input);  
	//斷言確認是否計算了平方  
	Assertions.assertEquals(expected, result);  
}  
  
@Test  
@DisplayName("入參大于等于100，計算其減1的值")  
public void givenGreaterThanOrEquals100() {  
	int input = 100;  
	int expected = 99;  
	//實際計算  
	int result = strangeCalculator.calculate(input);  
	//斷言確認是否計算了平方  
	Assertions.assertEquals(expected, result);  
}

運行所有單元測驗，可以看到有測驗用例沒有通過：

• 第二步、綠燈

實作第二次迭代的業務邏輯：

public class StrangeCalculator {

	public int calculate(int input) {  
	  
		if (input >= 100) {  
			//第二次迭代時，大于等于100的區間還是走老邏輯  
			return doGivenGreaterThan0(input);  
		} else if (input > 0) {  
			//第二次迭代的業務邏輯  
			return input * input;  
		} else if (input < 0) {  
			return doGivenLessThan0(input);  
		} else {  
			return doGivenEquals0(input);  
		}  
	}  
	  
	private int doGivenEquals0(int input) {  
		return 0;  
	}  
	  
	private int doGivenLessThan0(int input) {  
		return input + 1;  
	}  
	  
	private int doGivenGreaterThan0(int input) {  
		return input - 1;  
	}  
}

執行所有的測驗用例，此時第二次迭代的givenGreaterThan0AndLessThan100和givenGreaterThanOrEquals100這兩個用例都通過了，但是givenGreaterThan0卻沒有通過：

這是為什么呢？這是因為邊界條件發生了改變，givenGreaterThan0用例中的引數input=1，對應的是0<input<100的邊界條件，此時已經調整了，0<input<100需要計算input的平方，而不是input-1，

我們審查之前迭代的單元測驗用例，可以看到givenGreaterThan0的邊界已經被givenGreaterThan0AndLessThan100和givenGreaterThanOrEquals100覆寫到了，

一方面givenGreaterThan0對應的業務邏輯改變了，一方面已經有其他測驗用例覆寫了givenGreaterThan0的邊界條件，因此，我們可以將givenGreaterThan0移除了，

@Test  
@DisplayName("入參大于0，將其減1并回傳")  
public void givenGreaterThan0() {  
	int input = 1;  
	int expected = 0;  
	int result = strangeCalculator.calculate(input);  
	Assertions.assertEquals(expected, result);  
}

@Test  
@DisplayName("入參大于0且小于100，計算其平方")  
public void givenGreaterThan0AndLessThan100() {  
	//于0且小于100的入參  
	int input = 3;  
	int expected = 9;  
	//實際計算  
	int result = strangeCalculator.calculate(input);  
	//斷言確認是否計算了平方  
	Assertions.assertEquals(expected, result);  
}  
  
@Test  
@DisplayName("入參大于等于100，計算其減1的值")  
public void givenGreaterThanOrEquals100() {  
	//于0且小于100的入參  
	int input = 100;  
	int expected = 99;  
	//實際計算  
	int result = strangeCalculator.calculate(input);  
	//斷言確認是否計算了平方  
	Assertions.assertEquals(expected, result);  
}

將givenGreaterThan0移除后，重新執行單元測驗：

這次執行通過了，我們也將測驗用例維護在最新的業務規則下，

• 第三步、重構

測驗用例通過后，我們便可以進行重構了，

首先，抽取0<input<100邊界內的邏輯，形成私有方法；

其次，input>=0邊界條件下的doGivenGreaterThan0方法，如今已經名不副實，因此重新命名為doGivenGreaterThanOrEquals100，

重構后代碼如下：

public class StrangeCalculator {  

	public int calculate(int input) {  
	  
		if (input >= 100) {  
			//第二次迭代時，大于等于100的區間還是走老邏輯  
			// return doGivenGreaterThan0(input);  
			return doGivenGreaterThanOrEquals100(input);  
		} else if (input > 0) {
			//第二次迭代的業務邏輯
			return doGivenGreaterThan0AndLessThan100(input);  
		} else if (input < 0) {  
			return doGivenLessThan0(input);  
		} else {  
			return doGivenEquals0(input);  
		}  
	}  
	  
	private int doGivenGreaterThan0AndLessThan100(int input) {  
		return input * input;  
	}  
	  
	private int doGivenEquals0(int input) {  
		return 0;  
	}  
	  
	private int doGivenGreaterThanOrEquals100(int input) {  
		return input + 1;  
	}  
	  
	private int doGivenGreaterThan100(int input) {  
		return input - 1;  
	}  
}

5.1.3 第三次迭代

第三次迭代以及之后的迭代，都按照第二次迭代的思路進行開發，

5.2 貧血模型三層架構的TDD實戰

貧血三層架構的模型是貧血模型，因此只需要對Controller、Service、Dao這三層進行分別探討即可，

5.2.1 Dao層單元測驗用例

嚴格地說，Dao層的測驗屬于集成測驗，因為Dao層的SQL陳述句其實是寫給資料庫去執行的，只有真正連接資料庫進行集成測驗時，我們才能確認是否正常執行，

Dao層的測驗，我們希望驗證自己寫的Mapper方法是否能正常操作，例如某個ResultMap漏了欄位、某個#{}沒有正常賦值，

我們引入記憶體資料庫（如H2資料庫），通過集成到應用中的記憶體資料庫模擬外部資料庫，確保了單元測驗的獨立性，也提高了Dao層單元測驗的速度，也使我們可以提前做一些測驗，盡量提前發現一些問題，

H2記憶體資料庫的配置，詳細可以到本文配套的專案案例tdd-example/tdd-example-02中查看，案例地址如下：

https://github.com/feiniaojin/tdd-example

以下是mybatis-generator逆向生成的mapper，我們把它作為Dao層單元測驗的例子，一般來說逆向生成的mapper屬于可信任代碼，所有不會再進行測驗，在此僅作案例，

Dao層Mapper的代碼如下：

public interface CmsArticleMapper {  
	int deleteByPrimaryKey(Long id);  
	  
	int insert(CmsArticle record);  
	  
	CmsArticle selectByPrimaryKey(Long id);  
	  
	List<CmsArticle> selectAll();  
	  
	int updateByPrimaryKey(CmsArticle record);  
}

Dao層Mapper的測驗代碼如下：

@ExtendWith(SpringExtension.class)  
@SpringBootTest  
@AutoConfigureTestDatabase  
public class CmsArticleMapperTest {  
	  
	@Resource  
	private CmsArticleMapper mapper;  
	  
	@Test  
	public void testInsert() {  
		CmsArticle article = new CmsArticle();  
		article.setId(0L);  
		article.setArticleId("ABC123");  
		article.setContent("content");  
		article.setTitle("title");  
		article.setVersion(1L);  
		article.setModifiedTime(new Date());  
		article.setDeleted(0);  
		article.setPublishState(0);  
		int inserted = mapper.insert(article);  
		Assertions.assertEquals(1, inserted);  
	}  
	  
	@Test  
	public void testUpdateByPrimaryKey() {  
		CmsArticle article = new CmsArticle();  
		article.setId(1L);  
		article.setArticleId("ABC123");  
		article.setContent("content");  
		article.setTitle("title");  
		article.setVersion(1L);  
		article.setModifiedTime(new Date());  
		article.setDeleted(0);  
		article.setPublishState(0);  
		int updated = mapper.updateByPrimaryKey(article);  
		Assertions.assertEquals(1, updated);  
	}  
	  
	@Test  
	public void testSelectByPrimaryKey() {  
		CmsArticle article = mapper.selectByPrimaryKey(2L);  
		Assertions.assertNotNull(article);  
		Assertions.assertNotNull(article.getTitle());  
		Assertions.assertNotNull(article.getContent());  
	}  
}

5.2.2 Service層單元測驗用例

重點關注的一層，為了確保用例執行的效率以及屏蔽基礎設施呼叫，Service層所有對基礎設施的呼叫都應該Mock掉，

Service層的代碼如下：

@Service  
public class ArticleServiceImpl implements ArticleService {  
	  
	@Resource  
	private CmsArticleMapper mapper;  
	  
	@Resource  
	private IdServiceGateway idServiceGateway;  
	  
	@Override  
	public void createDraft(CreateDraftCmd cmd) {  
	  
		CmsArticle article = new CmsArticle();  
		article.setArticleId(idServiceGateway.nextId());  
		article.setContent(cmd.getContent());  
		article.setTitle(cmd.getTitle());  
		article.setPublishState(0);  
		article.setVersion(1L);  
		article.setCreatedTime(new Date());  
		article.setModifiedTime(new Date());  
		article.setDeleted(0);  
		mapper.insert(article);  
	}  
	  
	@Override  
	public CmsArticle getById(Long id) {  
		return mapper.selectByPrimaryKey(id);  
	}  
}

Service層的測驗代碼如下：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE,  
classes = {ArticleServiceImpl.class})  
@ExtendWith(SpringExtension.class)  
public class ArticleServiceImplTest {  
  
	@Resource  
	private ArticleService articleService;  
	  
	@MockBean  
	IdServiceGateway idServiceGateway;  
	  
	@MockBean  
	private CmsArticleMapper cmsArticleMapper;  
	  
	@Test  
	public void testCreateDraft() {  
	  
		Mockito.when(idServiceGateway.nextId()).thenReturn("123");  
		Mockito.when(cmsArticleMapper.insert(Mockito.any())).thenReturn(1);  
		  
		CreateDraftCmd createDraftCmd = new CreateDraftCmd();  
		createDraftCmd.setTitle("test-title");  
		createDraftCmd.setContent("test-content");  
		articleService.createDraft(createDraftCmd);  
		  
		Mockito.verify(idServiceGateway, Mockito.times(1)).nextId();  
		Mockito.verify(cmsArticleMapper, Mockito.times(1)).insert(Mockito.any());  
	}  
	  
	@Test  
	public void testGetById() {  
		CmsArticle article = new CmsArticle();  
		article.setId(1L);  
		article.setTitle("testGetById");  
		Mockito.when(cmsArticleMapper.selectByPrimaryKey(Mockito.any())).thenReturn(article);  
		  
		CmsArticle byId = articleService.getById(1L);  
		  
		Assertions.assertNotNull(byId);  
		Assertions.assertEquals(1L,byId.getId());  
		Assertions.assertEquals("testGetById",byId.getTitle());  
	}
}

通過Jacoco的覆寫率報告可以看到Service的邏輯都覆寫到了：

5.2.3 Controller層單元測驗用例

非常薄的一層，按照預想是不涉及業務邏輯的，如果只涉及內外模型的轉換，因此單元測驗可忽略，如果實在想測一下，可以使用MockMvc，

Controller的代碼如下：

@RestController  
@RequestMapping("/article")  
public class ArticleController {  
	  
	@Resource  
	private ArticleService articleService;  
	  
	@RequestMapping("/createDraft")  
	public void createDraft(@RequestBody CreateDraftCmd cmd) {  
		articleService.createDraft(cmd);  
	}  
	  
	@RequestMapping("/get")  
	public CmsArticle get(Long id) {  
		CmsArticle article = articleService.getById(id);  
		return article;  
	}
}

Controller的測驗代碼如下：

@ExtendWith(SpringExtension.class)  
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK,  
classes = {ArticleController.class})  
@EnableWebMvc  
public class ArticleControllerTest {  
	  
	@Resource  
	WebApplicationContext webApplicationContext;  
	  
	MockMvc mockMvc;  
	  
	@MockBean  
	ArticleService articleService;  
	  
	//初始化mockmvc  
	@BeforeEach  
	void setUp() {  
		mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();  
	}  
	  
	@Test  
	void testCreateDraft() throws Exception {  
	  
		CreateDraftCmd cmd = new CreateDraftCmd();  
		cmd.setTitle("test-controller-title");  
		cmd.setContent("test-controller-content");  
		  
		ObjectMapper mapper = new ObjectMapper();  
		String valueAsString = mapper.writeValueAsString(cmd);  
		  
		Mockito.doNothing().when(articleService).createDraft(Mockito.any());  
		  
		mockMvc.perform(MockMvcRequestBuilders  
		//訪問的URL和引數  
		.post("/article/createDraft")  
		.content(valueAsString)  
		.contentType(MediaType.APPLICATION_JSON))  
		//期望回傳的狀態碼  
		.andExpect(MockMvcResultMatchers.status().isOk())  
		//輸出請求和回應結果  
		.andDo(MockMvcResultHandlers.print()).andReturn();  
	}  
	  
	@Test  
	void testGet() throws Exception {  
	  
		CmsArticle article = new CmsArticle();  
		article.setId(1L);  
		article.setTitle("testGetById");  
		  
		Mockito.when(articleService.getById(Mockito.any())).thenReturn(article);  
		  
		mockMvc.perform(MockMvcRequestBuilders  
		//訪問的URL和引數  
		.get("/article/get").param("id","1"))  
		//期望回傳的狀態碼  
		.andExpect(MockMvcResultMatchers.status().isOk())
		.andExpect(MockMvcResultMatchers.jsonPath("$.id").value(1L))
		//輸出請求和回應結果  
		.andDo(MockMvcResultHandlers.print()).andReturn();  
	}  
}

通過Jacoco的覆寫率報告可以看到Controller的邏輯都覆寫到了：

5.3 DDD下的TDD實戰

DDD下的TDD實戰，我們以《手把手教你落地DDD》一文的案例工程ddd-example-cms為例進行講解，案例代碼將實作在該專案中，

ddd-example-cms專案地址為：

https://github.com/feiniaojin/ddd-example-cms

DDD中各層的測驗用例可以參考貧血模型，只做細微調整即可：

Application層的測驗用例可以參考Service層單元測驗用例進行撰寫；

Infrastructure層的測驗用例代碼可以參考Dao層單元測驗用例進行撰寫；

User Interface層可以參考Controller層單元測驗用例進行撰寫；

在此不多加贅述，詳細實作可以到案例工程ddd-example-cms中查看，

5.3.1 物體的單元測驗

物體的單元測驗，要考慮兩方面：創建物體必須覆寫其業務規則；業務操作必須復合其業務規則，

@Data  
public class ArticleEntity extends AbstractDomainMask {  
	  
	/**  
	* article業務主鍵  
	*/  
	private ArticleId articleId;  
	  
	/**  
	* 標題  
	*/  
	private ArticleTitle title;  
	  
	/**  
	* 內容  
	*/  
	private ArticleContent content;  
	  
	/**  
	* 發布狀態，[0-待發布；1-已發布]  
	*/  
	private Integer publishState;  
	  
	/**  
	* 創建草稿  
	*/  
	public void createDraft() {  
		this.publishState = PublishState.TO_PUBLISH.getCode();  
	}  
	  
	/**  
	* 修改標題  
	*  
	* @param articleTitle  
	*/  
	public void modifyTitle(ArticleTitle articleTitle) {  
		this.title = articleTitle;  
	}  
	  
	/**  
	* 修改正文  
	*  
	* @param articleContent  
	*/  
	public void modifyContent(ArticleContent articleContent) {  
		this.content = articleContent;  
	}  
	
	/**  
	* 發布  
	*/
	public void publishArticle() {  
		this.publishState = PublishState.PUBLISHED.getCode();  
	}  
}

測驗用例如下：

public class ArticleEntityTest {  
	  
	@Test  
	@DisplayName("創建草稿")  
	public void testCreateDraft() {  
		ArticleEntity entity = new ArticleEntity();  
		entity.setTitle(new ArticleTitle("title"));  
		entity.setContent(new ArticleContent("content12345677890"));  
		entity.createDraft();  
		Assertions.assertEquals(PublishState.TO_PUBLISH.getCode(), entity.getPublishState());  
	}  
	  
	@Test  
	@DisplayName("修改標題")  
	public void testModifyTitle() {  
		ArticleEntity entity = new ArticleEntity();  
		entity.setTitle(new ArticleTitle("title"));  
		entity.setContent(new ArticleContent("content12345677890"));  
		ArticleTitle articleTitle = new ArticleTitle("new-title");  
		entity.modifyTitle(articleTitle);  
		Assertions.assertEquals(articleTitle.getValue(), entity.getTitle().getValue());  
	}  
	  
	@Test  
	@DisplayName("修改正文")  
	public void testModifyContent() {  
		ArticleEntity entity = new ArticleEntity();  
		entity.setTitle(new ArticleTitle("title"));  
		entity.setContent(new ArticleContent("content12345677890"));  
		ArticleContent articleContent = new ArticleContent("new-content12345677890");  
		entity.modifyContent(articleContent);  
		Assertions.assertEquals(articleContent.getValue(), entity.getContent().getValue());  
	}  
	  
	@Test  
	@DisplayName("發布")  
	public void testPublishArticle() {  
		ArticleEntity entity = new ArticleEntity();  
		entity.setTitle(new ArticleTitle("title"));  
		entity.setContent(new ArticleContent("content12345677890"));  
		entity.publishArticle();  
		Assertions.assertEquals(PublishState.PUBLISHED.getCode(), entity.getPublishState());  
	}  
}

5.3.2 值物件的單元測驗

值物件的單元測驗，主要是必須覆寫其業務規則，以ArticleTitle這個值物件為例：

public class ArticleTitle implements ValueObject<String> {  
  
	private final String value;  
	  
	  
	public ArticleTitle(String value) {  
		this.check(value);  
		this.value = https://www.cnblogs.com/jingdongkeji/p/value;  
	}  
	  
	private void check(String value) {  
		Objects.requireNonNull(value,"標題不能為空");  
		if (value.length() > 64) {  
			throw new IllegalArgumentException("標題過長");  
		}  
	}  
	  
	@Override  
	public String getValue() {  
		return this.value;  
	}  
}

其單元測驗為：

public class ArticleTitleTest {  
  
	@Test  
	@DisplayName("測驗業務規則，ArticleTitle為空拋例外")  
	public void whenGivenNull() {  
		Assertions.assertThrows(NullPointerException.class, () -> {  
			new ArticleTitle(null);  
		});  
	}  
	  
	@Test  
	@DisplayName("測驗業務規則，ArticleTitle值長度大于64拋例外")  
	public void whenGivenLengthGreaterThan64() {  
		Assertions.assertThrows(IllegalArgumentException.class, () -> {  
			new ArticleTitle("11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111");  
		});  
	}  
	  
	@Test  
	@DisplayName("測驗業務規則，ArticleTitle小于等于64正常創建")  
	public void whenGivenLengthEquals64() {  
		ArticleTitle articleTitle = new ArticleTitle("1111111111111111111111111111111111111111111111111111111111111111"); 
		Assertions.assertEquals(64, articleTitle.getValue().length());  
	}  
}

5.3.3 Factory的單元測驗

@Component  
public class ArticleDomainFactoryImpl implements ArticleFactory {  
  
@Override  
	public ArticleEntity newInstance(ArticleTitle title, ArticleContent content) {  
		ArticleEntity entity = new ArticleEntity();  
		entity.setTitle(title);  
		entity.setContent(content);  
		entity.setArticleId(new ArticleId(UUID.randomUUID().toString()));  
		entity.setPublishState(PublishState.TO_PUBLISH.getCode());  
		entity.setDeleted(0);  
		Date date = new Date();  
		entity.setCreatedTime(date);  
		entity.setModifiedTime(date);  
		return entity;  
	}  
}

我們將Factory實作在Application層，ArticleDomainFactoryImpl的測驗用例 和Service層的測驗用例是非常相似的，測驗代碼如下：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE,  
classes = {ArticleDomainFactoryImpl.class})  
@ExtendWith(SpringExtension.class)  
public class ArticleDomainFactoryImplTest {  
	  
	@Resource  
	private ArticleFactory articleFactory;  
	  
	@Test  
	@DisplayName("Factory創建新物體")  
	public void testNewInstance() {  
	  
		ArticleTitle articleTitle = new ArticleTitle("title");  
		ArticleContent articleContent = new ArticleContent("content1234567890");  
		  
		ArticleEntity instance = articleFactory.newInstance(articleTitle, articleContent);  
		
		// 創建新物體
		Assertions.assertNotNull(instance); 
		// 唯一標識正確賦值
		Assertions.assertNotNull(instance.getArticleId()); 
	}  
}

6. 總結

本文介紹了TDD的基本概念和實施方法，并提供了貧血模型三層架構和DDD下的TDD實戰案例，我們要理解做出任何改變都會有一個艱難的開始，將現有的軟體開發方法轉變為TDD也不例外，但只要我們堅持下去，最終必定能從TDD中受益，

作者：京東物流 覃玉杰

來源：京東云開發者社區

標籤：領域驅動設計

上一篇：驅動開發：內核LoadLibrary實作DLL注入

下一篇：返回列表