本文將對測試驅動開發（TDD）進行探討，主要內容有：TDD基本理解、TDD常見誤區、TDD技術選型，以及案例實戰。希望通過本文，讀者能夠理解掌握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中受益。
作者：京東物流 覃玉傑
來源：京東雲開發者社區
