手把手教你实战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中查看。

本案例的代码地址为：

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

5.1.1 第一次迭代

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

1输入：输入一个int类型的参数
2处理逻辑：
3	(1)入参大于0，计算其减1的值并返回；
4	(2)入参等于0，直接返回0；
5	(3)入参小于0，计算其加1的值并返回
6

接下来采用TDD进行开发。

• 第一步、红灯

编写测试用例，实现上文的需求，注意有三个边界条件，要覆盖完整。

1public class StrangeCalculatorTest {  
2	
3	private StrangeCalculator strangeCalculator;  
4	  
5	  
6	@BeforeEach  
7	public void setup() {  
8		strangeCalculator = new StrangeCalculator();  
9	}  
10	  
11	@Test  
12	@DisplayName("入参大于0，将其减1并返回")  
13	public void givenGreaterThan0() {  
14		//大于0的入参  
15		int input = 1;  
16		int expected = 0;  
17		//实际计算  
18		int result = strangeCalculator.calculate(input);  
19		//断言确认是否减1  
20		Assertions.assertEquals(expected, result);  
21	}  
22	  
23	@Test  
24	@DisplayName("入参小于0，将其加1并返回")  
25	public void givenLessThan0() {  
26		//小于0的入参  
27		int input = -1;  
28		int expected = 0;  
29		//实际计算  
30		int result = strangeCalculator.calculate(input);  
31		//断言确认是否减1  
32		Assertions.assertEquals(expected, result);  
33	}  
34	  
35	@Test  
36	@DisplayName("入参等于0，直接返回")  
37	public void givenEquals0() {  
38		//等于0的入参  
39		int input = 0;  
40		int expected = 0;  
41		  
42		//实际计算  
43		int result = strangeCalculator.calculate(input);  
44		//断言确认是否等于0  
45		Assertions.assertEquals(expected, result);  
46	}  
47}
48

此时StrangeCalculator类和calculate方法还没有创建，会IDE报红色提醒是正常的。

创建StrangeCalculator类和calculate方法，注意此时未实现业务逻辑，应当使测试用例不能通过，在此抛出一个UnsupportedOperationException异常。

1public class StrangeCalculator {
2
3	public int calculate(int input) {  
4		//此时未实现业务逻辑，因此抛一个不支持操作的异常，以便使测试用例不通过
5		throw new UnsupportedOperationException();  
6	}  
7}
8

运行所有的单元测试：

此时报告测试不通过：

• 第二步、绿灯

首先实现givenGreaterThan0这个测试用例对应的逻辑：

1public class StrangeCalculator {  
2	public int calculate(int input) {  
3		//大于0的逻辑  
4		if (input > 0) {  
5			return input - 1;  
6		}  
7		//未实现的边界依旧抛出UnsupportedOperationException异常
8		throw new UnsupportedOperationException();  
9	}  
10}
11

注意，我们目前只实现了input>0的边界条件，其他的条件我们应该继续抛出异常，以便使其不通过。

运行单元测试，此时有3个测试用例，其中只有两个出错了。

继续实现givenLessThan0用例对应的逻辑：

1public class StrangeCalculator {  
2	public int calculate(int input) {  
3
4		if (input > 0) {  
5			//大于0的逻辑  
6			return input - 1;  
7		} else if (input < 0) {
8			//小于0的逻辑  
9			return input + 1;  
10		}  
11		//未实现的边界依旧抛出UnsupportedOperationException异常
12		throw new UnsupportedOperationException();  
13	}  
14}
15

运行单元测试，此时有3个测试用例，其中有1个出错：

继续实现givenEquals0用例对应的逻辑：

1public class StrangeCalculator {  
2	public int calculate(int input) {  
3		//大于0的逻辑  
4		if (input > 0) {  
5			return input - 1;  
6		} else if (input < 0) {  
7			return input + 1;  
8		} else {  
9			return 0;  
10		}  
11	}  
12}
13

运行单元测试：此时3个测试用例都通过了：

此时，打开Jacoco的测试覆盖率报告（tdd-example的pom.xml文件中将报告生成的位置配置为target/jacoco-report），打开index.html。

可以看到，calculate所有的边界条件都覆盖到了。

• 第三步、重构

本案例calculate中只有简单的计算，在实际开发中，我们进行重构时，可以将具体的业务操作抽取为private方法，例如：

1public class StrangeCalculator { 
2
3	public int calculate(int input) {  
4		//大于0的逻辑  
5		if (input > 0) {  
6			return doGivenGreaterThan0(input);  
7		} else if (input < 0) {  
8			return doGivenLessThan0(input);  
9		} else {  
10			return doGivenEquals0(input);  
11		}  
12	}  
13	
14	private int doGivenEquals0(int input) {  
15		return 0;  
16	}  
17	
18	private int doGivenLessThan0(int input) {  
19		return input + 1;  
20	}  
21	
22	private int doGivenGreaterThan0(int input) {  
23		return input - 1;  
24	}  
25}
26

再次执行单元测试，测试通过。

查看Jacoco覆盖率的报告，可以看到每个边界条件都被覆盖到。

5.1.2 第二次迭代

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

1（1）针对大于0且小于100的input，不再计算其减1的值，而是计算其平方值；
2

第二个版本的需求对上一个迭代的边界条件做了调整，我们需要先根据本次迭代，整理出新的、完整的边界条件：

1（1）针对大于0且小于100的input，计算其平方值；
2（2）针对大于等于100的input，计算其减去1的值；
3（3）针对小于0的input,计算其加1的值；
4（4）针对等于0的input,返回0
5

此时，之前的测试用例的入参有可能已经不满足新的边界了，但是我们暂时先不管它，继续TDD的“红灯-绿灯-重构”的流程。

• 第一步，红灯

在StrangeCalculatorTest中编写新的单元测试用例，用来覆盖本次的两个边界条件。

1@Test  
2@DisplayName("入参大于0且小于100，计算其平方")  
3public void givenGreaterThan0AndLessThan100() {  
4
5	int input = 3;  
6	int expected = 9;  
7	//实际计算  
8	int result = strangeCalculator.calculate(input);  
9	//断言确认是否计算了平方  
10	Assertions.assertEquals(expected, result);  
11}  
12  
13@Test  
14@DisplayName("入参大于等于100，计算其减1的值")  
15public void givenGreaterThanOrEquals100() {  
16	int input = 100;  
17	int expected = 99;  
18	//实际计算  
19	int result = strangeCalculator.calculate(input);  
20	//断言确认是否计算了平方  
21	Assertions.assertEquals(expected, result);  
22}
23

运行所有单元测试，可以看到有测试用例没有通过：

• 第二步、绿灯

实现第二次迭代的业务逻辑：

1public class StrangeCalculator {
2
3	public int calculate(int input) {  
4	  
5		if (input >= 100) {  
6			//第二次迭代时，大于等于100的区间还是走老逻辑  
7			return doGivenGreaterThan0(input);  
8		} else if (input > 0) {  
9			//第二次迭代的业务逻辑  
10			return input * input;  
11		} else if (input < 0) {  
12			return doGivenLessThan0(input);  
13		} else {  
14			return doGivenEquals0(input);  
15		}  
16	}  
17	  
18	private int doGivenEquals0(int input) {  
19		return 0;  
20	}  
21	  
22	private int doGivenLessThan0(int input) {  
23		return input + 1;  
24	}  
25	  
26	private int doGivenGreaterThan0(int input) {  
27		return input - 1;  
28	}  
29}
30

执行所有的测试用例，此时第二次迭代的givenGreaterThan0AndLessThan100和givenGreaterThanOrEquals100这两个用例都通过了，但是givenGreaterThan0却没有通过：

这是为什么呢？这是因为边界条件发生了改变，givenGreaterThan0用例中的参数input=1，对应的是0<input<100的边界条件，此时已经调整了，0<input<100需要计算input的平方，而不是input-1。

我们审查之前迭代的单元测试用例，可以看到givenGreaterThan0的边界已经被givenGreaterThan0AndLessThan100和givenGreaterThanOrEquals100覆盖到了。

一方面givenGreaterThan0对应的业务逻辑改变了，一方面已经有其他测试用例覆盖了givenGreaterThan0的边界条件，因此，我们可以将givenGreaterThan0移除了。

1@Test  
2@DisplayName("入参大于0，将其减1并返回")  
3public void givenGreaterThan0() {  
4	int input = 1;  
5	int expected = 0;  
6	int result = strangeCalculator.calculate(input);  
7	Assertions.assertEquals(expected, result);  
8}
9
10@Test  
11@DisplayName("入参大于0且小于100，计算其平方")  
12public void givenGreaterThan0AndLessThan100() {  
13	//于0且小于100的入参  
14	int input = 3;  
15	int expected = 9;  
16	//实际计算  
17	int result = strangeCalculator.calculate(input);  
18	//断言确认是否计算了平方  
19	Assertions.assertEquals(expected, result);  
20}  
21  
22@Test  
23@DisplayName("入参大于等于100，计算其减1的值")  
24public void givenGreaterThanOrEquals100() {  
25	//于0且小于100的入参  
26	int input = 100;  
27	int expected = 99;  
28	//实际计算  
29	int result = strangeCalculator.calculate(input);  
30	//断言确认是否计算了平方  
31	Assertions.assertEquals(expected, result);  
32}
33

将givenGreaterThan0移除后，重新执行单元测试：

这次执行通过了，我们也将测试用例维护在最新的业务规则下。

• 第三步、重构

测试用例通过后，我们便可以进行重构了。

首先，抽取0<input<100边界内的逻辑，形成私有方法；

其次，input>=0边界条件下的doGivenGreaterThan0方法，如今已经名不副实，因此重新命名为doGivenGreaterThanOrEquals100。

重构后代码如下：

1public class StrangeCalculator {  
2
3	public int calculate(int input) {  
4	  
5		if (input >= 100) {  
6			//第二次迭代时，大于等于100的区间还是走老逻辑  
7			// return doGivenGreaterThan0(input);  
8			return doGivenGreaterThanOrEquals100(input);  
9		} else if (input > 0) {
10			//第二次迭代的业务逻辑
11			return doGivenGreaterThan0AndLessThan100(input);  
12		} else if (input < 0) {  
13			return doGivenLessThan0(input);  
14		} else {  
15			return doGivenEquals0(input);  
16		}  
17	}  
18	  
19	private int doGivenGreaterThan0AndLessThan100(int input) {  
20		return input * input;  
21	}  
22	  
23	private int doGivenEquals0(int input) {  
24		return 0;  
25	}  
26	  
27	private int doGivenGreaterThanOrEquals100(int input) {  
28		return input + 1;  
29	}  
30	  
31	private int doGivenGreaterThan100(int input) {  
32		return input - 1;  
33	}  
34}
35

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中查看，案例地址如下：

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

以下是mybatis-generator逆向生成的mapper，我们把它作为Dao层单元测试的例子。一般来说逆向生成的mapper属于可信任代码，所有不会再进行测试，在此仅作案例。

Dao层Mapper的代码如下：

1public interface CmsArticleMapper {  
2	int deleteByPrimaryKey(Long id);  
3	  
4	int insert(CmsArticle record);  
5	  
6	CmsArticle selectByPrimaryKey(Long id);  
7	  
8	List<CmsArticle> selectAll();  
9	  
10	int updateByPrimaryKey(CmsArticle record);  
11}
12

Dao层Mapper的测试代码如下：

1@ExtendWith(SpringExtension.class)  
2@SpringBootTest  
3@AutoConfigureTestDatabase  
4public class CmsArticleMapperTest {  
5	  
6	@Resource  
7	private CmsArticleMapper mapper;  
8	  
9	@Test  
10	public void testInsert() {  
11		CmsArticle article = new CmsArticle();  
12		article.setId(0L);  
13		article.setArticleId("ABC123");  
14		article.setContent("content");  
15		article.setTitle("title");  
16		article.setVersion(1L);  
17		article.setModifiedTime(new Date());  
18		article.setDeleted(0);  
19		article.setPublishState(0);  
20		int inserted = mapper.insert(article);  
21		Assertions.assertEquals(1, inserted);  
22	}  
23	  
24	@Test  
25	public void testUpdateByPrimaryKey() {  
26		CmsArticle article = new CmsArticle();  
27		article.setId(1L);  
28		article.setArticleId("ABC123");  
29		article.setContent("content");  
30		article.setTitle("title");  
31		article.setVersion(1L);  
32		article.setModifiedTime(new Date());  
33		article.setDeleted(0);  
34		article.setPublishState(0);  
35		int updated = mapper.updateByPrimaryKey(article);  
36		Assertions.assertEquals(1, updated);  
37	}  
38	  
39	@Test  
40	public void testSelectByPrimaryKey() {  
41		CmsArticle article = mapper.selectByPrimaryKey(2L);  
42		Assertions.assertNotNull(article);  
43		Assertions.assertNotNull(article.getTitle());  
44		Assertions.assertNotNull(article.getContent());  
45	}  
46}
47

5.2.2 Service层单元测试用例

重点关注的一层，为了确保用例执行的效率以及屏蔽基础设施调用，Service层所有对基础设施的调用都应该Mock掉。

Service层的代码如下：

1@Service  
2public class ArticleServiceImpl implements ArticleService {  
3	  
4	@Resource  
5	private CmsArticleMapper mapper;  
6	  
7	@Resource  
8	private IdServiceGateway idServiceGateway;  
9	  
10	@Override  
11	public void createDraft(CreateDraftCmd cmd) {  
12	  
13		CmsArticle article = new CmsArticle();  
14		article.setArticleId(idServiceGateway.nextId());  
15		article.setContent(cmd.getContent());  
16		article.setTitle(cmd.getTitle());  
17		article.setPublishState(0);  
18		article.setVersion(1L);  
19		article.setCreatedTime(new Date());  
20		article.setModifiedTime(new Date());  
21		article.setDeleted(0);  
22		mapper.insert(article);  
23	}  
24	  
25	@Override  
26	public CmsArticle getById(Long id) {  
27		return mapper.selectByPrimaryKey(id);  
28	}  
29}
30

Service层的测试代码如下：

1@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE,  
2classes = {ArticleServiceImpl.class})  
3@ExtendWith(SpringExtension.class)  
4public class ArticleServiceImplTest {  
5  
6	@Resource  
7	private ArticleService articleService;  
8	  
9	@MockBean  
10	IdServiceGateway idServiceGateway;  
11	  
12	@MockBean  
13	private CmsArticleMapper cmsArticleMapper;  
14	  
15	@Test  
16	public void testCreateDraft() {  
17	  
18		Mockito.when(idServiceGateway.nextId()).thenReturn("123");  
19		Mockito.when(cmsArticleMapper.insert(Mockito.any())).thenReturn(1);  
20		  
21		CreateDraftCmd createDraftCmd = new CreateDraftCmd();  
22		createDraftCmd.setTitle("test-title");  
23		createDraftCmd.setContent("test-content");  
24		articleService.createDraft(createDraftCmd);  
25		  
26		Mockito.verify(idServiceGateway, Mockito.times(1)).nextId();  
27		Mockito.verify(cmsArticleMapper, Mockito.times(1)).insert(Mockito.any());  
28	}  
29	  
30	@Test  
31	public void testGetById() {  
32		CmsArticle article = new CmsArticle();  
33		article.setId(1L);  
34		article.setTitle("testGetById");  
35		Mockito.when(cmsArticleMapper.selectByPrimaryKey(Mockito.any())).thenReturn(article);  
36		  
37		CmsArticle byId = articleService.getById(1L);  
38		  
39		Assertions.assertNotNull(byId);  
40		Assertions.assertEquals(1L,byId.getId());  
41		Assertions.assertEquals("testGetById",byId.getTitle());  
42	}
43}
44

通过Jacoco的覆盖率报告可以看到Service的逻辑都覆盖到了：

5.2.3 Controller层单元测试用例

非常薄的一层，按照预想是不涉及业务逻辑的，如果只涉及内外模型的转换，因此单元测试可忽略。如果实在想测一下，可以使用MockMvc。

Controller的代码如下：

1@RestController  
2@RequestMapping("/article")  
3public class ArticleController {  
4	  
5	@Resource  
6	private ArticleService articleService;  
7	  
8	@RequestMapping("/createDraft")  
9	public void createDraft(@RequestBody CreateDraftCmd cmd) {  
10		articleService.createDraft(cmd);  
11	}  
12	  
13	@RequestMapping("/get")  
14	public CmsArticle get(Long id) {  
15		CmsArticle article = articleService.getById(id);  
16		return article;  
17	}
18}
19

Controller的测试代码如下：

1@ExtendWith(SpringExtension.class)  
2@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK,  
3classes = {ArticleController.class})  
4@EnableWebMvc  
5public class ArticleControllerTest {  
6	  
7	@Resource  
8	WebApplicationContext webApplicationContext;  
9	  
10	MockMvc mockMvc;  
11	  
12	@MockBean  
13	ArticleService articleService;  
14	  
15	//初始化mockmvc  
16	@BeforeEach  
17	void setUp() {  
18		mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();  
19	}  
20	  
21	@Test  
22	void testCreateDraft() throws Exception {  
23	  
24		CreateDraftCmd cmd = new CreateDraftCmd();  
25		cmd.setTitle("test-controller-title");  
26		cmd.setContent("test-controller-content");  
27		  
28		ObjectMapper mapper = new ObjectMapper();  
29		String valueAsString = mapper.writeValueAsString(cmd);  
30		  
31		Mockito.doNothing().when(articleService).createDraft(Mockito.any());  
32		  
33		mockMvc.perform(MockMvcRequestBuilders  
34		//访问的URL和参数  
35		.post("/article/createDraft")  
36		.content(valueAsString)  
37		.contentType(MediaType.APPLICATION_JSON))  
38		//期望返回的状态码  
39		.andExpect(MockMvcResultMatchers.status().isOk())  
40		//输出请求和响应结果  
41		.andDo(MockMvcResultHandlers.print()).andReturn();  
42	}  
43	  
44	@Test  
45	void testGet() throws Exception {  
46	  
47		CmsArticle article = new CmsArticle();  
48		article.setId(1L);  
49		article.setTitle("testGetById");  
50		  
51		Mockito.when(articleService.getById(Mockito.any())).thenReturn(article);  
52		  
53		mockMvc.perform(MockMvcRequestBuilders  
54		//访问的URL和参数  
55		.get("/article/get").param("id","1"))  
56		//期望返回的状态码  
57		.andExpect(MockMvcResultMatchers.status().isOk())
58		.andExpect(MockMvcResultMatchers.jsonPath("$.id").value(1L))
59		//输出请求和响应结果  
60		.andDo(MockMvcResultHandlers.print()).andReturn();  
61	}  
62}
63

通过Jacoco的覆盖率报告可以看到Controller的逻辑都覆盖到了：

5.3 DDD下的TDD实战

DDD下的TDD实战，我们以《手把手教你落地DDD》一文的案例工程ddd-example-cms为例进行讲解，案例代码将实现在该项目中。

ddd-example-cms项目地址为：

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

DDD中各层的测试用例可以参考贫血模型，只做细微调整即可：

Application层的测试用例可以参考Service层单元测试用例进行编写；

Infrastructure层的测试用例代码可以参考Dao层单元测试用例进行编写；

User Interface层可以参考Controller层单元测试用例进行编写；

在此不多加赘述，详细实现可以到案例工程ddd-example-cms中查看。

5.3.1 实体的单元测试

实体的单元测试，要考虑两方面：创建实体必须覆盖其业务规则；业务操作必须复合其业务规则。

1@Data  
2public class ArticleEntity extends AbstractDomainMask {  
3	  
4	/**  
5	* article业务主键  
6	*/  
7	private ArticleId articleId;  
8	  
9	/**  
10	* 标题  
11	*/  
12	private ArticleTitle title;  
13	  
14	/**  
15	* 内容  
16	*/  
17	private ArticleContent content;  
18	  
19	/**  
20	* 发布状态，[0-待发布；1-已发布]  
21	*/  
22	private Integer publishState;  
23	  
24	/**  
25	* 创建草稿  
26	*/  
27	public void createDraft() {  
28		this.publishState = PublishState.TO_PUBLISH.getCode();  
29	}  
30	  
31	/**  
32	* 修改标题  
33	*  
34	* @param articleTitle  
35	*/  
36	public void modifyTitle(ArticleTitle articleTitle) {  
37		this.title = articleTitle;  
38	}  
39	  
40	/**  
41	* 修改正文  
42	*  
43	* @param articleContent  
44	*/  
45	public void modifyContent(ArticleContent articleContent) {  
46		this.content = articleContent;  
47	}  
48	
49	/**  
50	* 发布  
51	*/
52	public void publishArticle() {  
53		this.publishState = PublishState.PUBLISHED.getCode();  
54	}  
55}
56

测试用例如下：

1public class ArticleEntityTest {  
2	  
3	@Test  
4	@DisplayName("创建草稿")  
5	public void testCreateDraft() {  
6		ArticleEntity entity = new ArticleEntity();  
7		entity.setTitle(new ArticleTitle("title"));  
8		entity.setContent(new ArticleContent("content12345677890"));  
9		entity.createDraft();  
10		Assertions.assertEquals(PublishState.TO_PUBLISH.getCode(), entity.getPublishState());  
11	}  
12	  
13	@Test  
14	@DisplayName("修改标题")  
15	public void testModifyTitle() {  
16		ArticleEntity entity = new ArticleEntity();  
17		entity.setTitle(new ArticleTitle("title"));  
18		entity.setContent(new ArticleContent("content12345677890"));  
19		ArticleTitle articleTitle = new ArticleTitle("new-title");  
20		entity.modifyTitle(articleTitle);  
21		Assertions.assertEquals(articleTitle.getValue(), entity.getTitle().getValue());  
22	}  
23	  
24	@Test  
25	@DisplayName("修改正文")  
26	public void testModifyContent() {  
27		ArticleEntity entity = new ArticleEntity();  
28		entity.setTitle(new ArticleTitle("title"));  
29		entity.setContent(new ArticleContent("content12345677890"));  
30		ArticleContent articleContent = new ArticleContent("new-content12345677890");  
31		entity.modifyContent(articleContent);  
32		Assertions.assertEquals(articleContent.getValue(), entity.getContent().getValue());  
33	}  
34	  
35	@Test  
36	@DisplayName("发布")  
37	public void testPublishArticle() {  
38		ArticleEntity entity = new ArticleEntity();  
39		entity.setTitle(new ArticleTitle("title"));  
40		entity.setContent(new ArticleContent("content12345677890"));  
41		entity.publishArticle();  
42		Assertions.assertEquals(PublishState.PUBLISHED.getCode(), entity.getPublishState());  
43	}  
44}
45

5.3.2 值对象的单元测试

值对象的单元测试，主要是必须覆盖其业务规则，以ArticleTitle这个值对象为例：

1public class ArticleTitle implements ValueObject<String> {  
2  
3	private final String value;  
4	  
5	  
6	public ArticleTitle(String value) {  
7		this.check(value);  
8		this.value = value;  
9	}  
10	  
11	private void check(String value) {  
12		Objects.requireNonNull(value, "标题不能为空");  
13		if (value.length() > 64) {  
14			throw new IllegalArgumentException("标题过长");  
15		}  
16	}  
17	  
18	@Override  
19	public String getValue() {  
20		return this.value;  
21	}  
22}
23

其单元测试为：

1public class ArticleTitleTest {  
2  
3	@Test  
4	@DisplayName("测试业务规则，ArticleTitle为空抛异常")  
5	public void whenGivenNull() {  
6		Assertions.assertThrows(NullPointerException.class, () -> {  
7			new ArticleTitle(null);  
8		});  
9	}  
10	  
11	@Test  
12	@DisplayName("测试业务规则，ArticleTitle值长度大于64抛异常")  
13	public void whenGivenLengthGreaterThan64() {  
14		Assertions.assertThrows(IllegalArgumentException.class, () -> {  
15			new ArticleTitle("11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111");  
16		});  
17	}  
18	  
19	@Test  
20	@DisplayName("测试业务规则，ArticleTitle小于等于64正常创建")  
21	public void whenGivenLengthEquals64() {  
22		ArticleTitle articleTitle = new ArticleTitle("1111111111111111111111111111111111111111111111111111111111111111"); 
23		Assertions.assertEquals(64, articleTitle.getValue().length());  
24	}  
25}
26

5.3.3 Factory的单元测试

1@Component  
2public class ArticleDomainFactoryImpl implements ArticleFactory {  
3  
4@Override  
5	public ArticleEntity newInstance(ArticleTitle title, ArticleContent content) {  
6		ArticleEntity entity = new ArticleEntity();  
7		entity.setTitle(title);  
8		entity.setContent(content);  
9		entity.setArticleId(new ArticleId(UUID.randomUUID().toString()));  
10		entity.setPublishState(PublishState.TO_PUBLISH.getCode());  
11		entity.setDeleted(0);  
12		Date date = new Date();  
13		entity.setCreatedTime(date);  
14		entity.setModifiedTime(date);  
15		return entity;  
16	}  
17}
18

我们将Factory实现在Application层，ArticleDomainFactoryImpl的测试用例 和Service层的测试用例是非常相似的。测试代码如下：

1@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE,  
2classes = {ArticleDomainFactoryImpl.class})  
3@ExtendWith(SpringExtension.class)  
4public class ArticleDomainFactoryImplTest {  
5	  
6	@Resource  
7	private ArticleFactory articleFactory;  
8	  
9	@Test  
10	@DisplayName("Factory创建新实体")  
11	public void testNewInstance() {  
12	  
13		ArticleTitle articleTitle = new ArticleTitle("title");  
14		ArticleContent articleContent = new ArticleContent("content1234567890");  
15		  
16		ArticleEntity instance = articleFactory.newInstance(articleTitle, articleContent);  
17		
18		// 创建新实体
19		Assertions.assertNotNull(instance); 
20		// 唯一标识正确赋值
21		Assertions.assertNotNull(instance.getArticleId()); 
22	}  
23}
24

6. 总结

本文介绍了TDD的基本概念和实施方法，并提供了贫血模型三层架构和DDD下的TDD实战案例。我们要理解做出任何改变都会有一个艰难的开始，将现有的软件开发方法转变为TDD也不例外，但只要我们坚持下去，最终必定能从TDD中受益。

作者：京东物流 覃玉杰

来源：京东云开发者社区