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/archive/2023/06/14/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中受益，
作者：京東物流 覃玉杰
來源：京東云開發者社區
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/555130.html
標籤：其他
下一篇：返回列表