1. 从"单元测试--"这个标题说起：先别急着写代码
我一直觉得，"单元测试"这四个字后面跟两个破折号，比跟一句完整的定义更有意思。它暗示了一种状态：单元测试这件事，做了，但没做完；写了，但没写透；跑了，但没跑对。很多团队对单元测试的态度就是这样，卡在半路，不上不下。
没有引号的话，很多人对单元测试的理解停留在"给代码写测试"这个层面。可一旦真正去写，会发现一连串问题：测试什么才算一个单元？怎么让测试不依赖数据库和网络？为什么JUnit和TestNG都叫测试框架，用起来完全两个套路？为什么Vue项目一配单元测试就报错，而且每个人报的错还不一样？这些问题如果不先想清楚，测试代码写得越多，后面维护成本越高。
这篇东西就是围绕这些具体问题展开的。我会把单元测试从概念、标准、工具选型到Vue项目里的报错排查，再到工程化落地，按实际操作顺序过一遍。适合刚准备给项目引入单元测试的团队，也适合那些已经写了几个测试但总觉得哪里不对的人。
1.1 为什么标题敢留一个"--"：单元测试的起点是"未完成"
先说个反直觉的结论：单元测试最忌讳的是"一次写完"。真正写单元测试的人，往往会故意让测试先失败，再让代码通过测试。这个"红-绿-重构"循环里，红（失败）是起点，不是错误。所以标题里那个"--"，我理解成"测试代码还没写完"的状态，而不是"不知道说什么"。
这个心态很重要。很多新手拿到一段业务代码，第一反应是"我怎么测它"，而不是"它应该有什么行为"。前者是以代码实现为中心，后者是以行为契约为中心。单元测试测的是行为，不是实现。如果你发现测试代码写起来特别痛苦，大概率不是测试的问题，而是被测代码本身的设计有问题。一个方法干了太多事、隐式依赖全局状态、返回值靠System.out而不是return，这些代码都很难测。难测本身就是代码坏味道的信号。
所以"未完成"还有一层意思：单元测试不是一个独立的交付物，它是代码设计的镜子。你写完一个功能，顺手写两个测试，发现自己根本没法构造输入，那就要回头改生产代码。这个反馈循环会逼着你把函数拆小、把依赖注入进来、把不可控的外部I/O隔离开。这个价值，比测试本身跑过几个用例重要得多。
1.2 单元测试到底在测什么
我见过不少团队把单元测试写成了"集成测试的简化版"，测一个Service方法，还要连数据库、发HTTP请求、读配置文件。这不是单元测试，这是给自己找麻烦。
单元测试的核心约束是：隔离。被测的"单元"只依赖内存中的对象，所有外部协作对象都用测试替身（stub、mock、fake）替代。为什么必须隔离？因为单元测试要解决的核心问题是：当出现回归时，你能在几分钟内定位到是哪一个类出了问题，而不是面对一整条调用链无从下手。
具体测什么，可以分成几个层次：
- 纯逻辑层：比如金额计算、状态流转、字符串处理、权限判断。这类代码没有I/O，输入输出明确，是单元测试收益最高的地方。
- 对象协作层：比如一个服务类调用了另一个服务类再到仓储类，你需要用mock隔离掉下游，只验证当前对象的行为。
- 异常与边界：空指针、集合为空、数值溢出、并发竞争。这些平时不会触发但一旦触发就是线上事故的场景，是最值得写测试的。
注意，单元测试不负责测"系统能不能跑起来"，那是冒烟测试和集成测试的事。也不负责测"性能达不达标"，那是压测的事。边界划清楚，测试的目标才明确。
1.3 单元测试的"单元"到底切多小
"单元"的大小没有绝对标准，但有一个经验法则：你的测试能不能不启动Spring容器、不启动Web服务器就跑起来。如果能，你的单元基本合格；如果需要启动容器、连数据库，那就不是单元测试，而是集成测试了。
具体到粒度，我习惯这样切分：
- 一个public方法对应一组测试方法，而不是一个测试方法。一个方法可能有正常路径、边界值、异常分支，这些分别写成一个test方法，名字里带上场景。
- 被测类只依赖抽象接口，不依赖具体实现类，这样mock才能插进去。
- 一个测试方法里只验证一个行为。如果你在一个test方法里又断言了返回值、又验证了mock调用次数、又检查了异常类型，说明这个测试的"单元"切大了，拆开。
切多小才合适？一个参考标准是：如果某段逻辑你会用if-else分支写超过三个分支，或者嵌套超过两层，就有必要把它拆成独立的方法并单独测试。分支复杂度越高，越需要单元测试保护。
2. 工具选型：JUnit、TestNG与Vue测试框架的取舍
单元测试的工具选型，看着简单，实际坑不少。后端Java圈，JUnit和TestNG是主流；前端Vue圈，Jest和Vitest是主流。但很多人直接照抄网上的配置，跑通就完事了，完全没搞懂这些工具各自的强项和适用场景。选错框架，后面写参数化测试、做并发测试、配覆盖率报告的时候，会各种别扭。
2.1 JUnit与TestNG的核心差异
JUnit 5和TestNG都能做单元测试，但设计理念不太一样。
先说JUnit 5。它是目前Java生态的默认选择，Spring Boot项目自带spring-boot-starter-test就包含JUnit 5。它的核心优势是跟现代Java配合得好：JUnit Jupiter的扩展模型（Extension）让自定义扩展变得很干净，比如@TempDir临时目录、@Timeout超时控制、@ParameterizedTest参数化测试，这些都是内置能力，基本满足日常需求。我们项目里跑常规的业务单测，JUnit 5是够用的。
再说TestNG。这个框架名字里的"NG"是Next Generation的意思，它一开始就想做"比JUnit更强"的测试框架。TestNG有几个独有能力是JUnit 5之前不具备的：
- 组（groups）：可以把测试方法分组，比如"fast""slow""database"，然后在testng.xml里灵活组合。我见过有些团队用这个特性区分冒烟测试和全量测试。
- 依赖测试（dependsOnMethods）：方法之间的执行顺序可控。这个特性要慎用，因为单元测试本应互相独立，但如果你确实有一段测试必须严格按顺序执行（比如同一个类里的init和destory场景），TestNG比JUnit 5好控制。
- 并发执行：TestNG可以用threadPoolSize和invocationCount直接做测试级并发，这在压测某些线程安全问题上很好用。
选择建议很简单：没有历史包袱的Java项目，直接用JUnit 5；对测试分组、顺序、并发有硬性需求的，考虑TestNG。如果你在维护老项目，项目里已经是TestNG，那也不急着迁移，两个框架可以在不同module里共存，没必要为统一而统一。
2.2 Vue项目测试框架组合：Jest + Vue Test Utils
Vue项目的单元测试选型，很多人一搜教程就上Jest + Vue Test Utils。这个组合确实经典，但你要清楚它为什么是这套，以及现在还有没有别的选择。
Jest是Facebook出的测试框架，特点是零配置、自带断言库、自带mock能力、自带覆盖率工具，而且测试文件是并行执行的，跑得很快。跟Vue Test Utils配合，可以直接挂载一个Vue组件，触发事件，断言渲染结果。Vue 2时代这是唯一的主流方案。
到了Vue 3 + Vite时代，一个更轻量的方案出现了：Vitest。它跟Vite共享配置，不需要像Jest那样搞一堆transform配置来兼容ES Module。如果你的项目已经是Vite驱动的Vue 3项目，我个人建议优先考虑Vitest。它不是"另一个Jest"，它底层用的就是Vite的依赖预打包和模块解析能力，运行速度明显更快，配置量也小一个量级。
不过要注意，Vue Test Utils对Vitest和Jest都支持。也就是说，你换Vitest不意味着要换组件测试的API。组件挂载、find、trigger、setProps这些用法是完全一致的。换个测试运行器，成本比想象中低。
2.3 单元测试标准：覆盖率不是唯一标准
"单元测试标准"这个话题，最常见的误区是把覆盖率当成KPI。我见过某个团队把行覆盖率要求定到90%，结果测试代码里全是"为了覆盖而覆盖"的断言：调用一下方法、不报错、就完事。这种测试除了让覆盖率数字好看，对质量没有任何帮助。
我理解的单元测试标准，优先级是这样排的：
- 发现回归的能力。这条测试在代码重构后能直接指出哪里行为变了，这是测试最核心的价值。
- 失败提示的明确性。好的测试失败时，断言信息能直接告诉你"期望2但得到1"，而不是抛出一个NullPointerException让人去猜。
- 执行速度。单测的执行速度应该以秒计。如果单测跑完要十分钟，那就说明你把它做成集成测试了。
- 稳定性。同样的代码，跑一百次，结果应该完全一致。如果有偶发失败，那是最伤团队信心的。
覆盖率这个指标，我把它当成辅助参考，而不是红线。新增代码的关键分支有没有测到，比总量覆盖到多少更重要。如果一个方法有10个分支，你测了9个，漏掉的那个恰好是异常时的兜底逻辑，那这个漏洞可能比覆盖50%但关键路径全测到的情况更危险。
我会在后面单独说一遍覆盖率报告怎么看，这里先记住一条：覆盖率要跟分支覆盖结合起来看，而且优先保证核心业务分支被覆盖。
3. 手写一个单元测试的完整过程
讲完工具和标准，进入实战。这一节我分两条线走：先写一个Java TestNG的用例，再写一个Vue组件的测试用例。这两条线覆盖了后端和前端的常见场景，也把前面说的"如何构造被测对象""如何注入依赖""如何断言"具体化。
3.1 被测代码与测试代码的分工
先说一个经常被忽略的问题：测试代码放在哪里。Maven项目默认的约定是src/main/java放生产代码，src/test/java放测试代码。很多人图方便把测试类放在生产目录旁边，这是错的。测试代码和生产代码应该物理隔离，这样打包的时候测试代码不会混进产物，构建时也能单独跑test阶段。
测试类的命名也有约定：JUnit和TestNG统一用被测类名+Test后缀，比如被测类是UserService，测试类就叫UserServiceTest。测试方法名不要用test开头这种啰嗦写法，直接写行为，比如shouldThrowExceptionWhenBalanceNotEnough，一眼能看出这个测试在验证什么。中文注释可以写，但方法名最好用英文，避免某些编码环境出乱码。
3.2 一个后端TestNG用例从零到跑通的过程
假设我们要测一个账户扣款的方法。原始代码长这样：
public class AccountService { private final AccountRepository accountRepository; private final NotificationClient notificationClient; public AccountService(AccountRepository accountRepository, NotificationClient notificationClient) { this.accountRepository = accountRepository; this.notificationClient = notificationClient; } public void deduct(String accountId, BigDecimal amount) { Account account = accountRepository.findById(accountId); if (account == null) { throw new AccountNotFoundException("account not found: " + accountId); } if (account.getBalance().compareTo(amount) < 0) { throw new InsufficientBalanceException("insufficient balance"); } account.setBalance(account.getBalance().subtract(amount)); accountRepository.save(account); notificationClient.sendDeductNotification(accountId, amount); } }这个类的两个依赖都是接口，很容易用mock替换。用TestNG的写法：
import org.testng.annotations.Test; import org.testng.annotations.BeforeMethod; import static org.mockito.Mockito.*; import static org.assertj.core.api.Assertions.assertThatThrownBy; import static org.assertj.core.api.Assertions.assertThat; public class AccountServiceTest { private AccountRepository accountRepository; private NotificationClient notificationClient; private AccountService accountService; @BeforeMethod public void setUp() { accountRepository = mock(AccountRepository.class); notificationClient = mock(NotificationClient.class); accountService = new AccountService(accountRepository, notificationClient); } @Test public void shouldDeductBalanceWhenAmountEnough() { Account account = new Account("acc-001", new BigDecimal("100.00")); when(accountRepository.findById("acc-001")).thenReturn(account); accountService.deduct("acc-001", new BigDecimal("30.00")); assertThat(account.getBalance()).isEqualByComparingTo("70.00"); verify(accountRepository).save(account); verify(notificationClient).sendDeductNotification("acc-001", new BigDecimal("30.00")); } @Test(expectedExceptions = InsufficientBalanceException.class) public void shouldThrowExceptionWhenBalanceNotEnough() { Account account = new Account("acc-001", new BigDecimal("10.00")); when(accountRepository.findById("acc-001")).thenReturn(account); accountService.deduct("acc-001", new BigDecimal("30.00")); } @Test public void shouldThrowExceptionWhenAccountNotFound() { when(accountRepository.findById("acc-001")).thenReturn(null); assertThatThrownBy(() -> accountService.deduct("acc-001", new BigDecimal("30.00"))) .isInstanceOf(AccountNotFoundException.class) .hasMessageContaining("acc-001"); } }这个例子看着简单，其实把单元测试的关键要素都放进来了：用@BeforeMethod统一初始化测试对象和mock，用when...thenReturn构造场景，用assertThat断言结果，用verify验证协作调用，用expectedExceptions或assertThatThrownBy断言异常。
有个细节值得说：第一个测试里我用isEqualByComparingTo而不是equals来比较BigDecimal。如果你用equals，BigDecimal("1.0")和BigDecimal("1.00")会判不等，因为scale不同；但业务上它们是同一个数值。用isEqualByComparingTo才能正确比较数值。这种"看着对但实际错"的坑，就是单元测试里最容易踩的类型之一。
3.3 一个前端Vue组件的单元测试怎么写
前端单测和后端逻辑不太一样。后端测的是数据流转和异常分支，前端组件测试侧重点在于：组件在不同props和用户交互下能否正确渲染和触发事件。
假设我们有这样一个Vue 3组件，一个商品卡片，显示名称和价格，点击加入购物车按钮会触发事件：
<template> <div class="product-card"> <h2>{{ product.name }}</h2> <p class="price">{{ formatPrice(product.price) }}</p> <button @click="handleAdd">加入购物车</button> </div> </template> <script setup> import { computed } from 'vue'; const props = defineProps({ product: { type: Object, required: true } }); const emit = defineEmits(['add']); const formatPrice = (price) => `￥${price.toFixed(2)}`; const handleAdd = () => { emit('add', props.product); }; </script>搭配Vitest和Vue Test Utils，测试这样写：
import { describe, it, expect, vi } from 'vitest'; import { mount } from '@vue/test-utils'; import ProductCard from '../ProductCard.vue'; describe('ProductCard', () => { it('正确渲染商品名称和格式化后的价格', () => { const wrapper = mount(ProductCard, { props: { product: { id: 1, name: '机械键盘', price: 399.5 } } }); expect(wrapper.find('h2').text()).toBe('机械键盘'); expect(wrapper.find('.price').text()).toBe('￥399.50'); }); it('点击加入购物车按钮后发出 add 事件', async () => { const product = { id: 2, name: '鼠标', price: 99 }; const wrapper = mount(ProductCard, { props: { product } }); await wrapper.find('button').trigger('click'); expect(wrapper.emitted('add')).toHaveLength(1); expect(wrapper.emitted('add')[0][0]).toEqual(product); }); });注意几点：
- mount和shallowMount的区别：shallowMount会替换掉子组件，只渲染当前组件本身。如果被测组件有很多子组件，shallowMount能减少干扰。但如果你的断言要检查子组件是否被正确渲染，那就要用mount。我一般默认shallowMount，需要测子组件交互再换成mount。
- trigger之后要await：Vue的DOM更新是异步的，如果trigger之后直接断言，可能拿到旧状态。await wrapper.find('button').trigger('click')就是为了等Vue完成一次tick。
- wrapper.emitted()：这是Vue Test Utils提供的API，用来断言组件发出的自定义事件。它返回一个以事件名为键的对象，值是一个数组，每个元素对应一次emit的参数列表。
4. vue + 单元测试报错场景拆解与排查
Vue项目接入单元测试，报错是常态。我见过最多的不是"不会写测试"，而是"环境都配不起来"。在这一节里，我把常见的报错分成几类，每类给出根因和排查思路。这些坑我都踩过，有些是配置问题，有些是版本兼容问题，有些是测试代码本身写错了。搞清楚它们的区别，能给你省下大量查资料的时间。
4.1 最常见的报错类型与根因
我把Vue单元测试相关的报错归纳为五类，大家可以对号入座：
| 报错特征 | 根本原因 | 解决思路 |
|---|---|---|
Cannot find module 'vue' | 测试运行器没有正确解析Vue的模块路径 | 检查Vitest/Jest的resolve.alias是否指向vue.runtime.esm-bundler.js等正确入口 |
document is not defined | 测试环境不是浏览器环境，缺少DOM API | 引入jsdom或happy-dom环境；Vitest配置environment: 'jsdom' |
window.matchMedia is not a function | jsdom环境缺少某些浏览器API | 在测试setup文件中为matchMedia或ResizeObserver等API编写mock实现 |
[Vue warn]: Failed to resolve component: xxx | 全局注册的组件没有在测试中注册 | 使用global.components配置或global.plugins注册需要的插件 |
SyntaxError: Cannot use import statement outside a module | Jest环境没有正确处理ES Module | Jest需要配置transform对.vue和.js文件做转译，或改用Vitest |
4.2 从报错信息反推问题：一个真实排查链路
拿我前段时间在一个Vue 3项目里遇到的情况举例。项目用Vite，要加单元测试，我先装了vitest和@vue/test-utils，跑了一个极简测试文件，报错是：
ReferenceError: document is not defined这个报错很典型。很多人第一反应是"我哪里用到了document？"其实根本不是业务代码的问题，而是Vitest默认的运行环境是node，node环境里没有DOM。你要在Vitest的配置里指定jsdom环境。
在vite.config.js里加：
import { defineConfig } from 'vite'; import vue from '@vitejs/plugin-vue'; export default defineConfig({ plugins: [vue()], test: { environment: 'jsdom', globals: true } });加了environment之后，又报了另一个错：
TypeError: Cannot read properties of undefined (reading 'value')这里就要看堆栈了。它指向的是@vue/test-utils内部混入的地方。这个一般是@vitejs/plugin-vue和@vue/test-utils的版本不匹配造成的。我在package.json里锁定版本后解决：@vitejs/plugin-vue要用4.x以上，@vue/test-utils要用2.x以上，跟Vue 3.3以上版本才配套。
排查链路走下来你会发现：报错本身并不可怕，关键是别报一个错就去改一个配置，要顺着错误信息往上游找根因。凡是涉及"You may need additional plugins/loaders""Cannot read properties of undefined""module not found"这类错误，先检查版本和模块解析配置，不要用奇怪的黑科技绕过。
4.3 解决"测试环境与开发环境不一致"的坑
Vue项目跑单测，最常见的隐性坑是：开发环境好好的，一进测试环境就报"组件没有渲染出内容""事件没有触发成功""props不生效"。这类问题往往不是测试代码错，而是测试环境里缺少开发环境的一些全局组件、指令或者插件。
举个例子：你的main.js里用app.use(ElementPlus)注册了整个UI库，组件模板里用了 。开发环境正常，但测试环境mount组件时，Vue Test Utils并没有自动加载ElementPlus，于是组件fallthrough到未知元素，断言button的文字就失败了。
解决办法是在测试setup文件里做全局配置：
// tests/setup.js import { config } from '@vue/test-utils'; config.global.plugins = [ElementPlus];或者针对某个测试文件单独配置：
const wrapper = mount(Component, { global: { plugins: [ElementPlus], directives: { loading: { mounted: () => {} } } } });这里的关键认知是：单测不是把整个应用启动起来再测，而是"组件 + 手动补齐依赖"。你在测试里看到的组件，是一个独立挂载的实例，应用入口的全局配置它一概不知。所以，最好把全局组件、指令、插件统一收敛到一个setup文件里管理，而不是在每个测试文件里零散地写。
还有一个细节：如果你的路由组件测试涉及router-link或useRouter，你得给测试传一个带router的全局plugin，或者直接mock掉useRouter。这个实践里经常被忽略，但一旦组件里用了路由，测试就会一堆警告。
5. 单元测试落地的工程化经验
测试写出来了，怎么让它持续发挥作用，而不是写完就忘？这一节讲工程化落地的事。我结合自己维护过多个中大型项目的经验，把测试目录规划、覆盖率门槛、持续集成接线，以及"怎么让同事愿意写测试"这四件事分别展开说。
5.1 测试目录规划与命名规范
测试代码不是写在某个文件里就完事，它需要长期维护，所以目录规划和命名规范很重要。我的经验是：测试结构尽量跟生产代码结构镜像对齐，而不是把所有测试堆在一个包（目录）里。
一个典型的后端项目结构：
src/ main/java/com/example/project/ user/ UserController.java UserService.java UserRepository.java test/java/com/example/project/ user/ UserControllerTest.java UserServiceTest.java UserRepositoryTest.java镜像结构的好处是：找测试的时候不用花心思，被测类在哪个包，测试就在哪个包。名字对应关系也简单，UserService对应UserServiceTest。
还有人问，测试要不要分单元测试、集成测试两个目录？我的建议是：如果集成测试数量不多，可以用命名后缀区分，比如UserServiceIT代表集成测试，UserServiceTest代表单元测试。如果集成测试很多，建议用Maven的failsafe插件和独立的目录src/test/java/.../integration来隔离，这样单测和集成测试可以分开跑，单测频率高，跑得快。
5.2 覆盖率门槛怎么定才合理
覆盖率一定要设门槛吗？我的结论是：要设，但别一刀切。设得太低没意义，设得太高会让团队把时间花在凑覆盖率上。
我建议用增量覆盖率而不是全局覆盖率来做门槛约束。在CI里跑diff，只统计本次变更涉及的代码行和分支覆盖。比如GitLab CI可以配合gcovr或者JaCoCo的变更覆盖率能力，要求新增代码的行覆盖率不低于80%，分支覆盖率不低于70%。这样既不会因为老代码坑多导致新需求被拖死，又能保证新增逻辑有基本的测试保护。
前端项目也类似。Vitest和Jest都有coverage阈值配置。不过前端经常遇到纯展示型组件和工具函数，覆盖率差异会很大。我一般会区分module来配置阈值：工具函数、状态管理逻辑要达到80%以上，页面级组件可以放宽到30%-40%，因为页面组件的测试成本和收益不成比例。
5.3 单测与持续集成的结合方式
单元测试不接CI，价值就少了一大半。没有CI强制，测试代码跑不跑完全靠自觉，项目一忙，测试就挂了没人管。接了CI之后，测试变成每次合并的必经关卡，才能发挥"安全网"的作用。
我推荐的做法是：CI流水线里，单元测试和集成测试分开跑。单元测试放在合并请求（MR）阶段，代码一push就触发，要求10分钟内跑完；集成测试放到每日构建或发布前阶段，耗时允许更长。
后端以GitLab CI为例，一个简单的job配置：
unit-test: stage: test script: - mvn test artifacts: when: always reports: junit: target/surefire-reports/TEST-*.xml把JUnit XML报告上传到CI平台之后，你就能在每个合并请求详情页看到测试用例的执行情况，哪个方法挂了，失败信息是什么，一目了然。
前端Vue项目同理，跑vitest run --coverage，然后把coverage/lcov.info上传到Codecov或SonarQube。可视化覆盖率趋势线有一个好处：它能直观地告诉你，这个项目的测试是越做越好，还是在不断恶化。
5.4 让人愿意维护测试的几条经验
最后说点软性的东西。很多团队单测推行不下去，不是技术问题，是"心态"问题。测试代码写起来麻烦、跑起来总挂、挂了没人敢改，久而久之大家就集体绕过它。我从实操中总结了几条经验：
第一，允许测试代码比生产代码啰嗦。很多人写测试时有一种"我要写得很优雅"的执念。测试代码追求优雅是好事，但不要以牺牲可读性为代价。测试里多写几行准备数据的代码，不要用复杂的工具类封装，因为测试的核心是让读者一眼看懂"前提是什么、操作是什么、期望是什么"。
第二，把"修补坏测试"的优先级提到功能开发之前。我见过很多团队，CI变红之后不是去修测试，而是把测试用例直接注释掉或加@Disabled跳过。这个口子一开，测试的保护作用就消失了。我的原则是，凡是进入主干的测试，必须保持全绿；如果某个测试确实已经过时，要明确地删除它，而不是跳过它。
第三，用测试作为代码评审的入口。我code review的时候，先看新增的测试，再看生产代码。如果测试代码写得清楚，那生产代码的实现意图就很明白。反过来，如果测试写得含糊、断言一堆没意义的值，那我就有理由怀疑生产代码的设计也含糊。把测试纳入review范围，既能提高测试质量，也能倒逼开发认真对待测试。
第四，别害怕重构测试代码。测试代码也是代码，也需要持续维护。生产代码改了API，测试代码就要跟着改。很多人因为测试代码改起来麻烦而抵触改生产代码，这其实是因噎废食。真正健康的代码库，生产代码和测试代码是一起演进、互相成就的。
我在实际项目中最大的体会是：单元测试的价值不在于写了多少行、覆盖率多高，而在于你改代码的时候心里有没有底。你改了一个公共方法，测试立刻告诉你下游哪些行为受影响，这种安全感是任何代码审查都替代不了的。把这个价值感传递到团队里，单测就不是上面压下来的任务，而是你自己想用起来的工具。
