你好！我是郑晔。
上一讲，我们讲了软件设计的第一步：分离关注点。作为至关重要的第一步，分离关注点常常被人忽略，严重影响了设计的有效性。这一讲，我们再来看另一个经常被很多人忽视的因素：可测试性。
在讨论可测试性之前，我们不妨先来思考一个问题：你觉得软件开发中最浪费时间的环节是什么？答案肯定不是写代码，因为写代码是一个建设的过程，谈不上是在浪费时间。在我接触过的诸多项目里，集成测试可以说是一个浪费时间的大户。
那你的项目是怎么做集成测试的呢？一个常见的测试场景是这样的：你先花了一些时间打包部署一个服务端应用，然后开始测试。测着测着，你发现一个Bug，然后调查半天，最后发现是一个简单的错误。你就在心里暗恨，为啥写代码的时候没发现呢！
这还只是一个简单的场景，也有稍微复杂一点的。比如，有多个不同项目组的人一起联合测试。当你测出一个Bug，然后辛辛苦苦调查半天，发现是另外一个模块出了问题，你唯一能做的就是等着那个组的同事把Bug改好，测试才能进行下去。更可恨的是，他们查了半天，结果也是一个简单的错误。你会在心里嘀咕，为啥写代码的时候不仔细一点呢？
在实际工作中，我们经常遇到类似的场景。你觉得这种状态正常吗？可能很多人对此习以为常。虽然难受，却不得不忍受。
但我想说的是，这样的问题原本有机会得到优化。而出现这样的问题，主要原因就在于前期设计时就埋下了隐患，你根本没有考虑“可测试性”。
软件设计要考虑“可测试性”
我们知道，软件开发要解决的问题是从需求而来。需求包括两大类，第一类是功能性需求，也就是要完成怎样的业务功能；第二类是非功能性需求，是业务功能之外的一些需求。
非功能性需求也被分为两大类，一类称为执行质量（Execution qualities），你所熟悉的吞吐、延迟、安全就属于这一类，它们都是可以在运行时通过运维手段被观察到的；而另一类称为演化质量（Evolution qualities），它们内含于一个软件的结构之中，包括可测试性、可维护性、可扩展性等。
做设计的时候，功能性需求自不必说，你肯定会考虑到。在非功能性需求中，执行质量是很多程序员的心头爱，一般也不会被忽略。但演化质量的地位却很低，常常为人忽略，尤其是其中的“可测试性”。
我们在开发过程中欠下的很多技术债，本质上都是因为忽略了“可测试性”这个需求。
可测试性为什么如此重要？因为我们做设计，其实就是把一个软件拆分成一个一个的小模块。如果不尽可能地保证每个小模块的正确性，而只是从最外围的系统角度去验证系统的正确性，这将会是一个非常困难的过程。就和盖楼是一个道理，不保证钢筋、水泥、砖土质量合格，却想要盖出合格的大楼来，很荒唐吧！然而，很多团队的软件开发就是这么做的。
我们要保证每个小模块的正确性，就要保证每个模块在开发阶段能够测试，而想要每个模块能够测试，在设计过程中，就要保证每个模块是可以测试的，而这就是可测试性。
一旦我们在可测试性上考虑不足，就会引发一系列的后续问题。比如，复杂的系统不仅仅在测试上有难度，在集成、部署等各个环节，都有其复杂性，完成一次部署往往也需要很长时间。
这也就意味着，即便是一个简单的验证工作，部署的时间成本也非常昂贵。这还不包括在出问题时，我们在一个复杂系统中定位问题的成本。
我们只有把每个小模块尽可能做好，才能尽量降低对集成环境的依赖程度，从而节省后期的成本。这就相当于在前面多花了1块钱，却省下了后期的10块钱。
我们回过头思考一下这节课刚开始提到的那个问题，为什么我们在集成测试场景中，会浪费那么多时间呢？因为这个系统只能在集成测试环境中进行测试，所以，即使是一些非常简单的问题，也只能在这阶段暴露。这些问题原本可以在更前面的阶段解决，比如，单元测试。
可为什么这些问题会遗留到集成测试环境呢？很多程序员给你的回答都会是，不好测。而这不好测的背后，往往就是因为在设计中没有考虑“可测试性”这个因素。
那么如何在设计中考虑可测试性呢？其实就是要在设计时想一下，这个函数/模块/系统要怎么测。
当你用这个标准衡量一些系统时，可能就会发现一种典型的错误，就是设计根本没有考虑过测试。这样的系统常常只有最外层的接口可以测试，也就是说，整个系统必须集成起来才能测试。前面提到的集成测试的问题犯下的就是这种错误。
在实际工作中，很多公司为了做集成测试，要把所有的子系统全部都搭建出来，也就是一套完整的环境。这种环境要占用大量的资源，一般来说，公司不会准备很多套。这样造成的结果就是各个团队对于环境的竞争，再叠加上各个系统配合的问题，测试的效率还会进一步降低。
所以，我们在设计一个函数/模块/系统时，必须将可测试性纳入考量，以便于能够完成不同层次的测试，减少对集成环境的依赖。
那么，具体该如何做呢？一方面，尽可能地给每个模块更多的测试，使构成系统的每个模块尽可能稳定，把集成测试环境更多地留作公共的验收资源。另一方面，尽可能搭建本地的集成测试环境，周边的系统可以采用模拟服务的方案。
在软件开发过程中考虑测试，实际上是思考软件的质量问题，而把质量的思考前移到开发，甚至是设计阶段，是软件开发从传统进入到现代的重要一步。
当你有了可测试性的视角
现在你已经对软件设计中的可测试性有了一个初步的认识。其实，在了解可测试性之后，我们还可以把它作为一个衡量标准来考察已有的设计。
比如，有一个设计模式叫Singleton，通常的做法是把构造函数做成私有的。如果这个Singleton的类与其他组件配合，由于这个私有函数的存在，这个类无法继承，也就不能用一个子类对象去模拟它。所以，从可测试性的角度来看，Singleton就不是一个好的设计模式。
再比如，TDD（Test-Driven Development，测试驱动开发）对于很多人来说都非常困难，主要有两方面原因。一方面，这些人不习惯先写测试的工作方式，但另外一方面，也是更重要的原因，是他们不知道怎么测试。
因为很多模块的设计根本没有考虑过如何做测试，要把它们单独拿出来测试，必然会遇到很多问题。
举个例子，在通常的架构中，服务会调用数据库访问的代码。如果是不考虑测试的做法，代码可能写成这样：
class ProductService {
// 访问数据库的对象
private ProduceRepository repository = new ProductRepository();
public Product find(final long id) {
return this.repository.find(id);
}
}
在这里，我们要直接创建数据库访问的对象，然而，要创建数据库访问对象，就要同时把数据库连接起来，你要准备一大堆相关的东西，所以，测试的复杂度就会非常大。
可是，测试这个服务目的是，关心这个服务的逻辑是不是写正确了，这与是不是用数据库没关系啊！所以，如果我考虑了可测试性，服务的依赖就变成了一个数据访问的接口：
class ProductService {
// 访问数据库的对象
private ProduceRepository repository;
public ProductService(final ProduceRepository repository) {
this.repository = repository;
}
public Product find(final long id) {
return this.repository.find(id);
}
}
在这种代码里，我们只需要将数据访问的接口模拟出来，而用来模拟接口的Mock框架在各种程序语言里几乎都可以找到。我们唯一要保证的，就是模拟出来的对象要与接口定义的行为保持一致，不过，这可比准备数据库，难度系数要低多了。
真正懂得了可测试性，还可以帮助我们理解软件开发的趋势。有些Java工作经验的同学可能听说过EJB（Enterprise Java Beans），它是2000年左右的开发主流。当时一个Java系统如果没用到EJB，你都不好意思和人打招呼。但是，今天你很难听说有谁还在用EJB做新系统了。
在每次测试时，EJB都需要部署到专门的应用服务器上。站在可测试性的角度看，它的测试成本就是极其高昂的，相应的开发成本也就变得很高。
当年与EJB竞争的正是当今如日中天的Spring，Spring胜出的一个重要原因就是它简化了开发。它当年的口号正是without EJB。这是一种重要的开发趋势：轻量级开发。而这背后，重要的思维基础，就是可测试性。后面在第五讲中，我们会讲到SpringDI容器的设计，你会进一步看到可测试性在其中发挥的作用。
实际上，Spring在简化开发的道路上从未停下脚步。今天的Java程序员使用Spring Boot的时候，启动它就像启动一个普通的Java应用，在IDE里做各种调试，甚至都没有注意到它启动时，下面有一个Tomcat。
要知道，当年可是要打出一个WAR包，部署到Tomcat上。所以，曾几何时，能够连接远程的Web服务器是IDE一项重要的功能，而这项功能在今天来看，已经非常鸡肋了。
总结时刻
今天，我们学习了一个影响软件设计的重要因素：可测试性。
在软件设计中，可测试性常常被人忽视，结果造成了很多模块的不可测，由此引发了很多技术债。所以，在设计中就要充分考虑可测试性。
在设计中考虑可测试性，就是在设计时问一下，这个函数/模块/系统怎么测。在软件开发中，只有把一个一个的小模块做了足够的测试，我们才会有稳定的构造块，才可以在集成测试的时候，只关注最终的结果。
而有了可测试性的视角，我们可以把它当作一个衡量标准去看待其他的设计或实践，也可以用它帮助我们理解软件的发展趋势。
经过前几讲基础知识的铺垫，你对软件设计已经有了一个初步的了解。下一讲，我们将进入到实际的工作环节中，去了解一个软件的设计。
如果今天的内容你只能记住一件事，那请记住：做软件设计，请考虑可测试性。
思考题
最后，我想请你回想一下，如果以可测试性衡量一下你开发过的系统，它的可测试性如何？有哪些问题是由于最初没有考虑可测试性造成的呢？欢迎在留言区分享你的经历。
感谢阅读，如果你觉得这一讲的内容对你有帮助的话，也欢迎把它分享给你的朋友。
精选留言
2020-05-29 00:15:46
2020-05-29 08:13:28
当private方法复杂并包含逻辑，其正确应当重构代码，而不是在测试做妥协，可以将需要测试的private方法转移到另一个对象中，成为一个public的方法。同时让我体会到测试驱动设计的含义。
2020-05-31 11:53:42
最近在给手上的代码上加测试的时候我进行了如下操作：
1. 我在测试类中写了一个测试，因为类A中要执行的这个逻辑需要依赖另外一个对象B，于是我把这个需要依赖的对象B从全局变量中移动到构造中，作为参数放了进去，然后再构造方法上加了注解@Autowired。（注意： 原来的这个@Autowired 是在这个全局变量上的）
2. 我在测试中mock 了这个依赖的B对象，然后给到了这个Service 的实例中去。
3. 写业务代码实现，让测试通过。
本来以为测试已经通过，没什么问题了，结果在集成测试启动Spring 容器的时候，发现挂掉了，发生了循环依赖，查看代码，果然，在B中也@Autowired 注入了A ，他们两个就此开始循环～～～～
结果用idea 的分析工具扫了一通，发现循环依赖不止于此，还有很多很多。。。。。
从这件事儿上体现出来的问题：
1: 滥用@Autowired 体现出来的首先就是没有分离关注点，让一个类中做了过多的事情。 现在想过来原来写过的很多代码里头都是一大堆的@Autowired 注入 ，很多XXXService 的代码大概率的会发生这种事情。
2: 其实IDEA 编译器里边早就提醒过你了，当你在字段上使用@Autowired 去注入的时候，会有黄线的提示，提醒你不要这么使用，推荐你使用构造器的方式去注入。而很多人的处理方式就是对这个黄线视而不见。
3：如果从代码的测试性的角度来出发，你一定不会这么做，因为这么做没有办法去mock 你的依赖。 代码会丑到你自己都不想看。
4: 以前没想过循环依赖是怎么发生的，现在明白了：一个罪魁祸首就是滥用@Autowired 。循环依赖本身也是一个设计上的坏味道。如果有人问我说如何解决循环依赖，我会回答他： 首先不要循环依赖。
2020-05-29 00:30:20
后来做过系统高可用软件，采用的方法是将代码自动部署到多个Docker里，测试代码里依据场景（为了方便，场景还用DSL写）比如杀某个Docker来测试高可用逻辑是否正常。
2020-05-29 08:27:53
2020-05-29 11:26:27
a.项目启动太慢(服务包启动一次7-8分钟，war包启动一次20几分钟)。虽然单测时我们可以控制扫包范围，但总会扫到一些"基础包"莫名其妙的玩意，逼着你只能扩大扫包范围，而扩大扫包范围就会让单元测试的间隔无意义的变长。（项目本身分层没规范。部分基础公共包的分层不规范，且强依赖，无法按需加载）
b.工具包大量非纯函数的工具。静态方法不采用mock框架的高级功能是mock不了的，所以往往我们不会去测试工具类的逻辑。但这些工具包往往也存在文档不全或文档和功能脱节的情况。这个时候，一旦你使用不当或者工具类有bug那么就可能出现与预期不符的情况，而这个排查起来是比较难受的。因为这往往是你排查的最后一步，而你可能没有权限，只能看着反编译的源码，找到问题也改不了。只能改动自己的功能不用这个工具。（由此可见DI是多么美好的东西）
c.臃肿的大类+强依赖中间数据结构。近百个字段的核心类，让你找个字段都很晕。中间数据(map,键值的list)在功能间传递，缺少封装。每次要获取自己要用的数据结构都要对中间数据做转换。逻辑走完后，还要对中间数据做变动，以保证变更对外部生效。这一切的结果就是逻辑被变得复杂了，代码行数增多了。而代码行数和逻辑变多出问题的可能就变大，测试的工作量就变大。
2.其他的，诸如不要有未决行为,尽量少用全局变量，低耦合等等都是个人编码能力的事，怪不得老项目了。提高可测试性,其实我觉得就是要遵循最小依赖的原则。最好就只有入参和本地逻辑（逻辑中没有外部依赖，没有外部变量，没有外部静态方法），这样可测试性是最好的。而要做到这个也并非不可能，全在你的设计和拆分力度上。
2020-05-29 06:28:47
感觉测试主要是为了防止自己或者别人改了自己的代码
2020-05-29 01:37:48
单元测试还有一个好处，那就是自动化。写一个功能，就运行一下单元测试。单元测试是代码功能的保障。经常对曾经一些低级的bug如手误少些个！之类的错误深恶痛绝，觉得怎么能犯这么低级的错误。我错怪自己了，人就是这样一种粗心的动物，应该让程序来检查代码的正确性，程序检查的又快又不会出错，何乐不为?当然前提是得有单元测试。
Tdd是一种好的实践。在测试上要多下点功夫。
2020-05-29 08:22:38
当然这也是建立在分解粒度要小的基础上，
2020-06-02 08:47:14
2020-05-29 10:26:23
2021-10-16 23:32:17
2020-06-03 07:59:38
2020-06-02 08:45:46
2020-05-30 15:06:03
那么这样无论是后台执行，还是涉及界面的调用逻辑，都是可测的。
2020-05-29 22:34:35
2021-06-28 09:58:15
2020-05-31 10:20:28
2020-05-30 23:14:27
在瀑布开发模式，或者是普通的团队中，测试人员一般都是在整个软件基本完成之后才开始进行测试。外部测试很难在函数或者模块级别开始介入。
在设计的时候，想一下这个模块要怎么测，其实就是考虑清楚这个模块要怎么调用。
之前接触过测试驱动开发，使用 Mock 框架来模拟各种外部访问资源，应该算是其中的高级技术话题。另外一个难点，是在于任务分解，所以我准备同步去学习《10X程序员工作法》。
如果没有单元测试和测试驱动开发，我觉的重构和持续集成也很难做好，主要是每次调试 bug 都需要比预计更多的时间。
做软件设计的时候，考虑可测试性，其实也算是“以终为始”的一种思维方式。
看了一下留言，虽然不多，但是藏龙卧虎。
老师在留言里面提到做好 TDD，前提是懂一点设计。我的理解是先有 TDD，然后重构，最终得到好的设计。当然，如果有一定的经验，知道什么是好的设计，无疑可以少走一点弯路。
2023-10-05 08:07:15
【R】软件开发最费时间的环节 = 集成测试。
【.I.】除了废大量时间在集成测试环节，更耗的是精力，以及最磨的是信心。满心欢喜开始集成测试，到发誓再也不要这样玩，除了爆弃式情绪释放，更要反思如何欢喜感保持、直到满足感升起。针对每个问题，盯着去质疑，如何在集成前可发现、如何在集成时易发现，是否为可测性迭代的最佳起点。
【R】非功能性需求 = ‘质量属性（Quality Attributes）’ = 执行质量（Execution Qualities）[=吞吐|延迟|安全|…]+ 演化质量（Evolution Qualities）[=可测试性+可维护性+可扩展性…]。
可测试性 = 技术债务之源头（造楼用的钢筋质量，是在混泥土灌入前单独质检，还是在大楼造成后整体验证）
【.I.】客户直接付钱的叫功能需求，客户潜在赔钱的叫执行质量，厂家持续利润的叫演化质量。功能需求决定当前单子的钱能不能收齐，执行质量决定未来新单子是否还来合作，演化质量决定挣到的钱多少可用于未来。
【R】设计函数、模块、系统时，可测性在不同层次纳入考量，本地模拟集成优先于真实集成环境。
【.I.】可测性，这个词本身容易带向具体的测试手段和方法，这本身没错，只是要认清楚，这些具体的测试手段和方法，它们是可测性的果。可测性本身作为因，要盯着去回答，何谓符合预期的正确、何谓预期之外的异常，以及什么信号和指标，准确反应这两方面的所谓。基于这样的追问得出的信号和指标，去指导整体设计和模块设计，去回答哪些在模块级解决、哪些到系统层面解决，再确定解决的具体方法和手段，即看到可测性时，脑子里直通的具体测试手段和方法。东西都是一样的，差别在于思考的路径。
【Q】可测性，在理论中学习掌握，跟在实践错误中反思理解，如何搭配出好方子？
---- by 术子米德@2023年10月5日