1. 前言
領(lǐng)域驅(qū)動設(shè)計，測試驅(qū)動開發(fā)。
我們在《手把手教你落地DDD》一文中介紹了領(lǐng)域驅(qū)動設(shè)計（DDD）的落地實戰(zhàn)，本文將對測試驅(qū)動開發(fā)（TDD）進行探討，主要內(nèi)容有：TDD基本理解、TDD常見誤區(qū)、TDD技術(shù)選型，以及案例實戰(zhàn)。希望通過本文，讀者能夠理解掌握TDD并將其應(yīng)用于實際開發(fā)中。
2. TDD基本理解
測試驅(qū)動開發(fā)（TDD）是一種軟件開發(fā)方法，要求開發(fā)者在編寫代碼之前先編寫測試用例，然后編寫代碼來滿足測試用例，最后運行測試用例來驗證代碼是否正確。測試驅(qū)動開發(fā)的基本流程如下：
2.1 第一步、編寫測試用例
在編寫代碼之前，先根據(jù)需求編寫測試用例，測試用例應(yīng)該覆蓋所有可能的情況，以確保代碼的正確性。
這一步又稱之為“紅燈”，因為沒有實現(xiàn)功能，此時測試用例執(zhí)行會失敗，在IDE里面執(zhí)行時會報錯，報錯為紅色。
2.2 第二步、運行測試用例
由于沒有編寫任何代碼來滿足這些測試用例，因此這些測試用例將會全部運行失敗。
2.3 第三步、編寫代碼
編寫代碼以滿足測試用例，在這個過程中，我們需要編寫足夠的代碼使所有的測試用例通過。
這一步又稱之為“綠燈”，在IDE里面執(zhí)行成功時是綠色的，非常形象。
2.4 第四步、運行測試用例
編寫代碼完成之后，運行測試用例，確保全部用例都通過。如果有任何一個測試用例失敗，就需要回到第三步，修改代碼，直至所有的用例都通過。
2.5 第五步、重構(gòu)代碼
在確保測試用例全部通過之后，可以對代碼進行重構(gòu)，例如將重復(fù)的代碼抽取成函數(shù)或類，消除冗余代碼等。
重構(gòu)的目的是提高代碼的可讀性、可維護性和可擴展性。重構(gòu)不改變代碼的功能，只是對代碼進行優(yōu)化，因此重構(gòu)之后的代碼必須依舊能通過測試用例。
2.6 第六步、運行測試用例
重構(gòu)之后的代碼，也必須保證通過全部的測試用例，否則需要修改至用例通過。
3. TDD常見的誤區(qū)
3.1 誤區(qū)一、單元測試就是TDD
單元測試是TDD的基礎(chǔ)，但單元測試并不等同于TDD。
單元測試是一種測試方法，它旨在驗證代碼中的單個組件（例如類或方法）是否按預(yù)期工作。
TDD是一種軟件開發(fā)方法，它強調(diào)在編寫代碼之前先編寫測試用例（即單元測試用例），并通過不斷運行測試用例來指導(dǎo)代碼的設(shè)計和實現(xiàn)。TDD是基于單元測試的，TDD的編寫的測試用例就是單元測試用例。
TDD還強調(diào)測試驅(qū)動開發(fā)過程中的重構(gòu)階段，在重構(gòu)階段優(yōu)化代碼結(jié)構(gòu)和設(shè)計，以提高代碼質(zhì)量和可維護性。單元測試通常不包括重構(gòu)階段，因為它們主要關(guān)注單元組件的功能性驗證。
3.2 誤區(qū)二、誤把集成測試當(dāng)成單元測試
TDD在很多團隊推不起來，甚至連單元測試都推不起來，歸根到底是大家對TDD和單元測試的理解有誤區(qū)。很多開發(fā)者在編寫測試用例時，以為自己編寫的是單元測試，但實際上寫的卻是集成測試的用例，原因就在于不理解單元測試和集成測試的區(qū)別。
單元測試是指對軟件中的最小可測試單元進行檢查和驗證的過程，通常是對代碼的單個函數(shù)或方法進行測試。單元測試的對象是代碼中的最小可測試單元，通常是一個函數(shù)或方法。單元測試的范圍通常局限于單個函數(shù)或方法，只關(guān)注該函數(shù)或方法對輸入數(shù)據(jù)的處理和輸出數(shù)據(jù)的正確性，不涉及到其他函數(shù)或方法的影響，也不考慮系統(tǒng)的整體功能。
集成測試是指將單元測試通過的模塊組合起來進行測試，以驗證它們在一起能否正常協(xié)作和運行。集成測試的對象是系統(tǒng)中的組件或模塊，通常是多個已通過單元測試的模塊組合起來進行測試。集成測試可以發(fā)現(xiàn)模塊之間的兼容問題、數(shù)據(jù)一致性問題、系統(tǒng)性能問題等。
在實際開發(fā)中，許多開發(fā)者只對最頂層的方法寫測試用例，例如直接對Controller方法編寫測試用例，然后啟動容器，讀寫外部數(shù)據(jù)庫，圖省事一股腦把Controller、Service、Dao全測了。 這實際上寫的是集成測試的用例，這會造成：
- 測試用例職責(zé)不單一
單元測試用例職責(zé)應(yīng)該單一，即只是驗證業(yè)務(wù)代碼的執(zhí)行邏輯，不確保與外部的集成，集成了外部服務(wù)或者中間件的測試用例，都應(yīng)視為集成測試。
- 測試用例粒度過大
只針對頂層的方法編寫測試用例（集成測試），忽略了許多過程中的public方法，會導(dǎo)致單元測試覆蓋率過低，代碼質(zhì)量得不到保障。
- 測試用例執(zhí)行太慢
由于需要依賴基礎(chǔ)設(shè)施（連接數(shù)據(jù)庫），會導(dǎo)致測試用例執(zhí)行得很慢，如果單元測試不能很快執(zhí)行完成，開發(fā)者往往會失去耐心，不會再繼續(xù)投入到單元測試中。
可以說，執(zhí)行慢是單元測試和TDD推不起來的非常大的原因。
結(jié)論：單元測試必須屏蔽基礎(chǔ)設(shè)施（外部服務(wù)、中間件）的調(diào)用，且單元測試僅用于驗證業(yè)務(wù)邏輯是否按預(yù)期執(zhí)行。
判斷自己寫的用例是否是單元測試用例，方法很簡單：只需要把開發(fā)者電腦的網(wǎng)絡(luò)關(guān)掉，如果能正常在本地執(zhí)行單元測試，那么基本寫的就是單元測試，否則均為集成測試用例。
2.3 誤區(qū)三、項目工期緊別寫單元測試了
開發(fā)者在將代碼提交測試時，我們往往要求先自測通過才能提測。那么，自測通過的依據(jù)是什么？我認為自測通過的依據(jù)是開發(fā)者編寫的單元測試用例運行通過、且覆蓋了所有本次開發(fā)相關(guān)的所有核心方法。
我們在需求排期時，可以將自測的時間考慮進去，為單元測試爭取足夠的時間。
越早的單元測試作用越大，我們可以及早發(fā)現(xiàn)代碼中的錯誤和缺陷，并及時進行修復(fù)，從而提高代碼的可靠性和質(zhì)量，而不是等到提測之后再修復(fù)，此時修復(fù)的成本更高。
在項目工期緊迫的情況下，更應(yīng)該堅持寫單元測試，這不會影響項目進度。相反，它可以幫助我們提高代碼的質(zhì)量和可靠性，減少錯誤和缺陷的出現(xiàn)，從而避免了后期因為錯誤導(dǎo)致的額外成本和延誤。
本文介紹了不少提交單元測試運行速度地方法，讀者可以將之應(yīng)用到實際項目中，減少單測對開發(fā)時間的影響。
2.4 誤區(qū)四、代碼完成后再補單元測試
任何時候?qū)憜卧獪y試都是值得鼓勵的，都能使我們從單元測試中受益。
代碼完成后再寫單元測試的做法會導(dǎo)致問題在開發(fā)過程中被忽略，并在后期被發(fā)現(xiàn)，從而增加了修復(fù)問題的成本和風(fēng)險。
TDD要求先寫測試用例再寫代碼，開發(fā)人員應(yīng)該在編寫代碼前就開始編寫相應(yīng)的測試用例，并在每次修改代碼后運行測試用例以確保代碼的正確性。
2.5 誤區(qū)五、對單元測試覆蓋率的極端要求
有的團隊要求單元測試覆蓋率要100%，有的團隊則對覆蓋率沒有要求。
理論上單元測試應(yīng)該覆蓋所有代碼和所有的邊界條件，在實際中我們還需要考慮投入產(chǎn)出比。
在TDD中，紅燈階段寫的測試用例，會覆蓋所有相關(guān)的public?的方法和邊界條件；在重構(gòu)階段，某些執(zhí)行邏輯被抽取為private方法，我們要求這些private方法中只執(zhí)行操作不再進行邊界判斷，因此重構(gòu)后產(chǎn)生的private方法我們不需要考慮其單元測試。
2.6 誤區(qū)六、單元測試只需要運行一次
許多開發(fā)人員認為，單元測試只要運行通過，證明自己寫的代碼滿足本次迭代需求就可以了，之后不需要再運行。
實際上，單元測試的生命周期時和項目代碼相同的，單元測試不只是運行一次，其影響會持續(xù)到項目下線。
每一次上線，都應(yīng)該全量執(zhí)行一遍單元測試，確保從前的測試用例都能通過，本次需求開發(fā)的代碼沒有影響到以前的邏輯，這樣做能避免很多線上的事故。
一些年代久遠的系統(tǒng)，我們對內(nèi)部邏輯不熟悉時，如何使變更范圍可控？答案就是全量執(zhí)行單元測試用例，假如從前的測試用例執(zhí)行不通過了，也就意味著我們本次開發(fā)影響了線上的邏輯。老系統(tǒng)沒有單元測試怎么辦？補。幸運的是現(xiàn)在有不少自動生成單元測試的工具，讀者可以自行研究。
4. TDD技術(shù)選型
4.1 單元測試框架
JUnit和TestNG都是非常優(yōu)秀的Java單元測試框架，任選其中一個都可以完整實踐TDD，本文采用JUnit 5。
4.2 模擬對象框架
在單元測試中，我們常常需要使用Mock進行模擬對象，以便模擬其行為，使得單元測試可以更容易地編寫。
Mock框架有很多，例如Mockito、PowerMock等，本文采用Mockito。
4.3 測試覆蓋率
本文采用Jacoco作為測試覆蓋率檢測工具。
Jacoco是一款Java代碼覆蓋率工具，它可以幫助開發(fā)人員在代碼編寫過程中監(jiān)測測試用例的覆蓋情況，以便更好地了解測試用例的質(zhì)量和代碼的可靠性。Jacoco可以在代碼執(zhí)行期間收集覆蓋信息，同時還可以生成報告，以便開發(fā)人員能夠更好地了解代碼的測試覆蓋率。
Jacoco還支持在Maven、Gradle等構(gòu)建工具中使用。開發(fā)人員可以通過在pom.xml或build.gradle文件中添加Jacoco插件來集成。
4.4 測試報告
測試報告框架有許多，例如Allure，讀者可自行研究學(xué)習(xí)。
5. TDD案例實戰(zhàn)
5.1 奇怪的計算器
本案例我們將實現(xiàn)一個奇怪的計算器，通過這個案例完整實踐TDD的幾個步驟。
限于篇幅，Maven pom文件、測試報告生成等配置就不貼出來了，請讀者自行到本案例代碼tdd-example/tdd-example-01中查看。
本案例的代碼地址為：
https://github.com/feiniaojin/tdd-example
5.1.1 第一次迭代
奇怪的計算器的需求如下：
輸入：輸入一個int類型的參數(shù)
處理邏輯：
(1)入?yún)⒋笥?，計算其減1的值并返回；
(2)入?yún)⒌扔?，直接返回0；
(3)入?yún)⑿∮?，計算其加1的值并返回
接下來采用TDD進行開發(fā)。
- 第一步、紅燈
編寫測試用例，實現(xiàn)上文的需求，注意有三個邊界條件，要覆蓋完整。
public class StrangeCalculatorTest {
private StrangeCalculator strangeCalculator;
@BeforeEach
public void setup() {
strangeCalculator = new StrangeCalculator();
}
@Test
@DisplayName("入?yún)⒋笥?，將其減1并返回")
public void givenGreaterThan0() {
//大于0的入?yún)?
int input = 1;
int expected = 0;
//實際計算
int result = strangeCalculator.calculate(input);
//斷言確認是否減1
Assertions.assertEquals(expected, result);
}
@Test
@DisplayName("入?yún)⑿∮?，將其加1并返回")
public void givenLessThan0() {
//小于0的入?yún)?
int input = -1;
int expected = 0;
//實際計算
int result = strangeCalculator.calculate(input);
//斷言確認是否減1
Assertions.assertEquals(expected, result);
}
@Test
@DisplayName("入?yún)⒌扔?，直接返回")
public void givenEquals0() {
//等于0的入?yún)?
int input = 0;
int expected = 0;
//實際計算
int result = strangeCalculator.calculate(input);
//斷言確認是否等于0
Assertions.assertEquals(expected, result);
}
}
此時StrangeCalculator類和calculate方法還沒有創(chuàng)建，會IDE報紅色提醒是正常的。
創(chuàng)建StrangeCalculator類和calculate方法，注意此時未實現(xiàn)業(yè)務(wù)邏輯，應(yīng)當(dāng)使測試用例不能通過，在此拋出一個UnsupportedOperationException異常。
public class StrangeCalculator {
public int calculate(int input) {
//此時未實現(xiàn)業(yè)務(wù)邏輯，因此拋一個不支持操作的異常，以便使測試用例不通過
throw new UnsupportedOperationException();
}
}
運行所有的單元測試：
此時報告測試不通過：
- 第二步、綠燈
首先實現(xiàn)givenGreaterThan0這個測試用例對應(yīng)的邏輯：
public class StrangeCalculator {
public int calculate(int input) {
//大于0的邏輯
if (input > 0) {
return input - 1;
}
//未實現(xiàn)的邊界依舊拋出UnsupportedOperationException異常
throw new UnsupportedOperationException();
}
}
注意，我們目前只實現(xiàn)了input>0的邊界條件，其他的條件我們應(yīng)該繼續(xù)拋出異常，以便使其不通過。
運行單元測試，此時有3個測試用例，其中只有兩個出錯了。
繼續(xù)實現(xiàn)givenLessThan0用例對應(yīng)的邏輯：
public class StrangeCalculator {
public int calculate(int input) {
if (input > 0) {
//大于0的邏輯
return input - 1;
} else if (input < 0) {
//小于0的邏輯
return input + 1;
}
//未實現(xiàn)的邊界依舊拋出UnsupportedOperationException異常
throw new UnsupportedOperationException();
}
}
運行單元測試，此時有3個測試用例，其中有1個出錯：
繼續(xù)實現(xiàn)givenEquals0用例對應(yīng)的邏輯：
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所有的邊界條件都覆蓋到了。
- 第三步、重構(gòu)
本案例calculate中只有簡單的計算，在實際開發(fā)中，我們進行重構(gòu)時，可以將具體的業(yè)務(wù)操作抽取為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;
}
}
再次執(zhí)行單元測試，測試通過。
查看Jacoco覆蓋率的報告，可以看到每個邊界條件都被覆蓋到。
5.1.2 第二次迭代
奇怪的計算器第二次迭代的需求如下：
（1）針對大于0且小于100的input，不再計算其減1的值，而是計算其平方值；
第二個版本的需求對上一個迭代的邊界條件做了調(diào)整，我們需要先根據(jù)本次迭代，整理出新的、完整的邊界條件：
（1）針對大于0且小于100的input，計算其平方值；
（2）針對大于等于100的input，計算其減去1的值；
（3）針對小于0的input,計算其加1的值；
（4）針對等于0的input,返回0
此時，之前的測試用例的入?yún)⒂锌赡芤呀?jīng)不滿足新的邊界了，但是我們暫時先不管它，繼續(xù)TDD的“紅燈-綠燈-重構(gòu)”的流程。
- 第一步，紅燈
在StrangeCalculatorTest中編寫新的單元測試用例，用來覆蓋本次的兩個邊界條件。
@Test
@DisplayName("入?yún)⒋笥?且小于100，計算其平方")
public void givenGreaterThan0AndLessThan100() {
int input = 3;
int expected = 9;
//實際計算
int result = strangeCalculator.calculate(input);
//斷言確認是否計算了平方
Assertions.assertEquals(expected, result);
}
@Test
@DisplayName("入?yún)⒋笥诘扔?00，計算其減1的值")
public void givenGreaterThanOrEquals100() {
int input = 100;
int expected = 99;
//實際計算
int result = strangeCalculator.calculate(input);
//斷言確認是否計算了平方
Assertions.assertEquals(expected, result);
}
運行所有單元測試，可以看到有測試用例沒有通過：
- 第二步、綠燈
實現(xiàn)第二次迭代的業(yè)務(wù)邏輯：
public class StrangeCalculator {
public int calculate(int input) {
if (input >= 100) {
//第二次迭代時，大于等于100的區(qū)間還是走老邏輯
return doGivenGreaterThan0(input);
} else if (input > 0) {
//第二次迭代的業(yè)務(wù)邏輯
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;
}
}
執(zhí)行所有的測試用例，此時第二次迭代的givenGreaterThan0AndLessThan100和givenGreaterThanOrEquals100這兩個用例都通過了，但是givenGreaterThan0卻沒有通過：
這是為什么呢？這是因為邊界條件發(fā)生了改變，givenGreaterThan0用例中的參數(shù)input=1，對應(yīng)的是0<input<100的邊界條件，此時已經(jīng)調(diào)整了，0<input<100需要計算input的平方，而不是input-1。
我們審查之前迭代的單元測試用例，可以看到givenGreaterThan0的邊界已經(jīng)被givenGreaterThan0AndLessThan100和givenGreaterThanOrEquals100覆蓋到了。
一方面givenGreaterThan0對應(yīng)的業(yè)務(wù)邏輯改變了，一方面已經(jīng)有其他測試用例覆蓋了givenGreaterThan0的邊界條件，因此，我們可以將givenGreaterThan0移除了。
@Test
@DisplayName("入?yún)⒋笥?，將其減1并返回")
public void givenGreaterThan0() {
int input = 1;
int expected = 0;
int result = strangeCalculator.calculate(input);
Assertions.assertEquals(expected, result);
}
@Test
@DisplayName("入?yún)⒋笥?且小于100，計算其平方")
public void givenGreaterThan0AndLessThan100() {
//于0且小于100的入?yún)?
int input = 3;
int expected = 9;
//實際計算
int result = strangeCalculator.calculate(input);
//斷言確認是否計算了平方
Assertions.assertEquals(expected, result);
}
@Test
@DisplayName("入?yún)⒋笥诘扔?00，計算其減1的值")
public void givenGreaterThanOrEquals100() {
//于0且小于100的入?yún)?
int input = 100;
int expected = 99;
//實際計算
int result = strangeCalculator.calculate(input);
//斷言確認是否計算了平方
Assertions.assertEquals(expected, result);
}
將givenGreaterThan0移除后，重新執(zhí)行單元測試：
這次執(zhí)行通過了，我們也將測試用例維護在最新的業(yè)務(wù)規(guī)則下。
- 第三步、重構(gòu)
測試用例通過后，我們便可以進行重構(gòu)了。
首先，抽取0<input<100邊界內(nèi)的邏輯，形成私有方法；
其次，input>=0邊界條件下的doGivenGreaterThan0方法，如今已經(jīng)名不副實，因此重新命名為doGivenGreaterThanOrEquals100。
重構(gòu)后代碼如下：
public class StrangeCalculator {
public int calculate(int input) {
if (input >= 100) {
//第二次迭代時，大于等于100的區(qū)間還是走老邏輯
// return doGivenGreaterThan0(input);
return doGivenGreaterThanOrEquals100(input);
} else if (input > 0) {
//第二次迭代的業(yè)務(wù)邏輯
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 第三次迭代
第三次迭代以及之后的迭代，都按照第二次迭代的思路進行開發(fā)。
5.2 貧血模型三層架構(gòu)的TDD實戰(zhàn)
貧血三層架構(gòu)的模型是貧血模型，因此只需要對Controller、Service、Dao這三層進行分別探討即可。
5.2.1 Dao層單元測試用例
嚴格地說，Dao層的測試屬于集成測試，因為Dao層的SQL語句其實是寫給數(shù)據(jù)庫去執(zhí)行的，只有真正連接數(shù)據(jù)庫進行集成測試時，我們才能確認是否正常執(zhí)行。
Dao層的測試，我們希望驗證自己寫的Mapper方法是否能正常操作，例如某個ResultMap漏了字段、某個#{}沒有正常賦值。
我們引入內(nèi)存數(shù)據(jù)庫（如H2數(shù)據(jù)庫），通過集成到應(yīng)用中的內(nèi)存數(shù)據(jù)庫模擬外部數(shù)據(jù)庫，確保了單元測試的獨立性，也提高了Dao層單元測試的速度，也使我們可以提前做一些測試，盡量提前發(fā)現(xiàn)一些問題。
H2內(nèi)存數(shù)據(jù)庫的配置，詳細可以到本文配套的項目案例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層單元測試用例
重點關(guān)注的一層，為了確保用例執(zhí)行的效率以及屏蔽基礎(chǔ)設(shè)施調(diào)用，Service層所有對基礎(chǔ)設(shè)施的調(diào)用都應(yīng)該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層單元測試用例
非常薄的一層，按照預(yù)想是不涉及業(yè)務(wù)邏輯的，如果只涉及內(nèi)外模型的轉(zhuǎn)換，因此單元測試可忽略。如果實在想測一下，可以使用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和參數(shù)
.post("/article/createDraft")
.content(valueAsString)
.contentType(MediaType.APPLICATION_JSON))
//期望返回的狀態(tài)碼
.andExpect(MockMvcResultMatchers.status().isOk())
//輸出請求和響應(yīng)結(jié)果
.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和參數(shù)
.get("/article/get").param("id","1"))
//期望返回的狀態(tài)碼
.andExpect(MockMvcResultMatchers.status().isOk())
.andExpect(MockMvcResultMatchers.jsonPath("$.id").value(1L))
//輸出請求和響應(yīng)結(jié)果
.andDo(MockMvcResultHandlers.print()).andReturn();
}
}
通過Jacoco的覆蓋率報告可以看到Controller的邏輯都覆蓋到了：
5.3 DDD下的TDD實戰(zhàn)
DDD下的TDD實戰(zhàn)，我們以《手把手教你落地DDD》一文的案例工程ddd-example-cms為例進行講解，案例代碼將實現(xiàn)在該項目中。
ddd-example-cms項目地址為：
https://github.com/feiniaojin/ddd-example-cms
DDD中各層的測試用例可以參考貧血模型，只做細微調(diào)整即可：
Application層的測試用例可以參考Service層單元測試用例進行編寫；
Infrastructure層的測試用例代碼可以參考Dao層單元測試用例進行編寫；
User Interface層可以參考Controller層單元測試用例進行編寫；
在此不多加贅述，詳細實現(xiàn)可以到案例工程ddd-example-cms中查看。
5.3.1 實體的單元測試
實體的單元測試，要考慮兩方面：創(chuàng)建實體必須覆蓋其業(yè)務(wù)規(guī)則；業(yè)務(wù)操作必須復(fù)合其業(yè)務(wù)規(guī)則。
@Data
public class ArticleEntity extends AbstractDomainMask {
/**
* article業(yè)務(wù)主鍵
*/
private ArticleId articleId;
/**
* 標(biāo)題
*/
private ArticleTitle title;
/**
* 內(nèi)容
*/
private ArticleContent content;
/**
* 發(fā)布狀態(tài)，[0-待發(fā)布；1-已發(fā)布]
*/
private Integer publishState;
/**
* 創(chuàng)建草稿
*/
public void createDraft() {
this.publishState = PublishState.TO_PUBLISH.getCode();
}
/**
* 修改標(biāo)題
*
* @param articleTitle
*/
public void modifyTitle(ArticleTitle articleTitle) {
this.title = articleTitle;
}
/**
* 修改正文
*
* @param articleContent
*/
public void modifyContent(ArticleContent articleContent) {
this.content = articleContent;
}
/**
* 發(fā)布
*/
public void publishArticle() {
this.publishState = PublishState.PUBLISHED.getCode();
}
}
測試用例如下：
public class ArticleEntityTest {
@Test
@DisplayName("創(chuàng)建草稿")
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("修改標(biāo)題")
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("發(fā)布")
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 值對象的單元測試
值對象的單元測試，主要是必須覆蓋其業(yè)務(wù)規(guī)則，以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, "標(biāo)題不能為空");
if (value.length() > 64) {
throw new IllegalArgumentException("標(biāo)題過長");
}
}
@Override
public String getValue() {
return this.value;
}
}
其單元測試為：
public class ArticleTitleTest {
@Test
@DisplayName("測試業(yè)務(wù)規(guī)則，ArticleTitle為空拋異常")
public void whenGivenNull() {
Assertions.assertThrows(NullPointerException.class, () -> {
new ArticleTitle(null);
});
}
@Test
@DisplayName("測試業(yè)務(wù)規(guī)則，ArticleTitle值長度大于64拋異常")
public void whenGivenLengthGreaterThan64() {
Assertions.assertThrows(IllegalArgumentException.class, () -> {
new ArticleTitle("11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111");
});
}
@Test
@DisplayName("測試業(yè)務(wù)規(guī)則，ArticleTitle小于等于64正常創(chuàng)建")
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實現(xiàn)在Application層，ArticleDomainFactoryImpl的測試用例 和Service層的測試用例是非常相似的。測試代碼如下：
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE,
classes = {ArticleDomainFactoryImpl.class})
@ExtendWith(SpringExtension.class)
public class ArticleDomainFactoryImplTest {
@Resource
private ArticleFactory articleFactory;
@Test
@DisplayName("Factory創(chuàng)建新實體")
public void testNewInstance() {
ArticleTitle articleTitle = new ArticleTitle("title");
ArticleContent articleContent = new ArticleContent("content1234567890");
ArticleEntity instance = articleFactory.newInstance(articleTitle, articleContent);
// 創(chuàng)建新實體
Assertions.assertNotNull(instance);
// 唯一標(biāo)識正確賦值
Assertions.assertNotNull(instance.getArticleId());
}
}
6. 總結(jié)
本文介紹了TDD的基本概念和實施方法，并提供了貧血模型三層架構(gòu)和DDD下的TDD實戰(zhàn)案例。我們要理解做出任何改變都會有一個艱難的開始，將現(xiàn)有的軟件開發(fā)方法轉(zhuǎn)變?yōu)門DD也不例外，但只要我們堅持下去，最終必定能從TDD中受益。
作者：京東物流 覃玉杰文章來源：http://www.zghlxwxcb.cn/news/detail-481844.html
來源：京東云開發(fā)者社區(qū)文章來源地址http://www.zghlxwxcb.cn/news/detail-481844.html
到了這里，關(guān)于手把手教你實戰(zhàn)TDD的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
