手把手教你实战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推不起来的非常大的原因。

结论：单元测试必须屏蔽基础设施（外部服务、中间件）的调用，且单元测试仅用于验证业务逻辑是否按预期执行。

判断自己写的用例是否是单元测试用例，方法很简单：只需要把开发者电脑的网络关掉，如果能正常在本地执行单元测试，那么基本写的就是单元测试，否则均为集成测试用例。

3.3 误区三、项目工期紧别写单元测试了

开发者在将代码提交测试时，我们往往要求先自测通过才能提测。那么，自测通过的依据是什么？我认为自测通过的依据是开发者编写的单元测试用例运行通过、且覆盖了所有本次开发相关的所有核心方法。

我们在需求排期时，可以将自测的时间考虑进去，为单元测试争取足够的时间。

越早的单元测试作用越大，我们可以及早发现代码中的错误和缺陷，并及时进行修复，从而提高代码的可靠性和质量，而不是等到提测之后再修复，此时修复的成本更高。

在项目工期紧迫的情况下，更应该坚持写单元测试，这不会影响项目进度。相反，它可以帮助我们提高代码的质量和可靠性，减少错误和缺陷的出现，从而避免了后期因为错误导致的额外成本和延误。

本文介绍了不少提交单元测试运行速度地方法，读者可以将之应用到实际项目中，减少单测对开发时间的影响。

3.4 误区四、代码完成后再补单元测试

任何时候写单元测试都是值得鼓励的，都能使我们从单元测试中受益。

代码完成后再写单元测试的做法会导致问题在开发过程中被忽略，并在后期被发现，从而增加了修复问题的成本和风险。

TDD要求先写测试用例再写代码，开发人员应该在编写代码前就开始编写相应的测试用例，并在每次修改代码后运行测试用例以确保代码的正确性。

3.5 误区五、对单元测试覆盖率的极端要求

有的团队要求单元测试覆盖率要100%，有的团队则对覆盖率没有要求。

理论上单元测试应该覆盖所有代码和所有的边界条件，在实际中我们还需要考虑投入产出比。

在TDD中，红灯阶段写的测试用例，会覆盖所有相关的public 的方法和边界条件；在重构阶段，某些执行逻辑被抽取为private方法，我们要求这些private方法中只执行操作不再进行边界判断，因此重构后产生的private方法我们不需要考虑其单元测试。

3.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 第一次迭代

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

输入