手把手教你實戰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 = 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中受益。

作者：京東物流 覃玉傑

來源：京東雲開發者社群