1. 面试官到底在考什么：TDD面试题的底层逻辑
1.1 从“背诵八股”到“手写测试”：面试考察点的变迁
这两年的Java后端面试，明显感觉到一个趋势：面试官不满足于你背出“TDD是测试驱动开发”这种一句话定义了。他们更希望你现场手写测试代码，现场讲解测试思路，甚至现场演示一遍红绿重构的完整过程。这个变化背后的原因很直接——光会背八股文的人太多了，但真正能在项目里把测试写好的人太少了。
我梳理了一下2025年各厂面试题里关于TDD的高频问法，基本可以分成三类。第一类是概念辨析类，比如“TDD和单元测试有什么区别”“Mock和Stub的区别是什么”。第二类是流程实操类，比如“给你一个用户注册接口，你怎么用TDD把它写出来”“先写测试还是先写实现，为什么”。第三类是工程决策类，比如“覆盖率做到多少才合适”“测试代码要不要也做重构”“怎么让团队接受TDD”。
这三类问题的难度是逐级递增的。概念类靠背就能过关，流程类需要你真刀真枪写过，工程决策类则要求你有过实际项目经验，踩过坑，才能给出有说服力的回答。我见过太多候选人挂在第二类上——概念说得头头是道，一让他上手写一个@WebMvcTest的测试，手就开始抖，连@MockBean和@InjectMocks的区别都说不清楚。
这就是我写这篇文章的初衷。我想把TDD从“面试八股”变成“面试武器”，让你不光能答出概念，还能在面试官面前写出一手漂亮的测试代码，把“我会TDD”变成“我能用TDD解决问题”。
1.2 三道经典TDD面试题的出题意图拆解
我们先看三道面试真题，把出题人的意图摸清楚，后续内容才有针对性。
第一题：“请用TDD实现一个密码强度校验器，规则是长度不少于8位、必须包含数字和字母。”
这道题看似简单，实际上考察了三个关键点。第一，你能不能先把测试用例列全——合法密码、太短的密码、纯数字密码、纯字母密码、空值、null值。第二，你能不能按照“先写一个失败的测试→写最小实现→重构”的顺序来推进，而不是上来就直接写完所有逻辑。第三，你的测试代码命名是否清晰，比如shouldRejectPasswordShorterThan8这种命名方式，别人一眼就能看懂测试意图。
第二题：“Spring Boot项目里，你要测试一个依赖Redis和数据库的Service方法，你会怎么写测试？”
这道题考察的是你对测试隔离的理解。很多候选人上来就说用@Testcontainers起一个真实的Redis和MySQL，这话本身没错，但面试官真正想听的是你能不能分清楚单元测试和集成测试的边界。单元测试里，Service依赖的外部组件应该用Mock来替代；集成测试里，才需要启动真实的容器。如果你能主动说出“这个方法我用Mockito把RedisTemplate和Mapper都Mock掉，只验证业务逻辑；另外再写一个@SpringBootTest的集成测试验证全链路”，面试官的眼睛会亮的。
第三题：“你上个项目里有没有写过单元测试？覆盖率是多少？怎么保证的？”
这道题最阴险的地方在于，它看似在问覆盖率，实际上在问你的工程素养。你光说“我们项目覆盖率80%”是没用的，你得说清楚这个数字是怎么统计的、是行覆盖率还是分支覆盖率、测试是放在CI流水线里强制执行还是靠自觉、遇到不好测的老代码怎么办。这些细节才是面试官真正想听的。
2. TDD核心知识点面试前必须吃透的概念框架
2.1 红绿重构循环的完整闭环
TDD的核心理念可以用一个循环来概括：红灯→绿灯→重构，然后再进入下一轮。面试的时候，如果你能把这个循环讲得有血有肉，而不是干巴巴地念定义，就已经超过一半的候选人了。
先看红灯阶段。这个阶段你要写一个失败的测试，重点在于“失败”要失败得有意义。我见过很多人写测试的时候，第一步就跑不通，因为Spring上下文都起不来——这种红色是无效的红色，证明你的测试基建就没搭好。有效的红色应该是：测试代码写好了，断言也写好了，运行之后因为被测代码还没实现而失败，或者因为实现逻辑有bug而失败。换句话说，失败的根源必须落在被测代码上，而不是测试环境上。
再看绿灯阶段。这个阶段的唯一目标是让测试通过，不追求代码质量。很多初学者在这个阶段会忍不住把生产代码写得特别完善，这是违背TDD精神的。面试官让你演示TDD的时候，你如果一步到位把整个校验逻辑全写完了，就丧失了展示TDD过程的机会。正确的做法是：写最少的生产代码让当前测试变绿，然后回到测试阶段再补下一个用例。
最后是重构阶段。测试全部通过之后，你手里有一个安全网，可以放心地优化生产代码——提取方法、消除重复、改善命名。重构完之后必须再跑一遍全部测试，确认没有破坏任何行为。这个阶段是我在面试中最爱观察的点，因为能主动做重构的候选人，说明他真的有TDD的肌肉记忆，而不是临时背了一堆概念。
面试的时候你可以这样说：“我会严格遵守红灯→绿灯→重构的循环。每次只写一个测试，等它红色之后写最少代码让它变绿，再做安全重构。这个过程大概3到5分钟一轮，最多10轮就能完成一个方法的开发。”
2.2 FIRST原则与RIGHT原则：概念题的标准答案
TDD相关的概念题里，问得最多的是测试原则。除了广为人知的FIRST原则，近两年的面试里RIGHT原则也在逐渐增多。
FIRST原则是五个单词的缩写。F是Fast，测试必须快，一个单元测试的运行时间应该以毫秒计，如果你的单元测试跑一次要好几分钟，那一定是你把集成测试混进单元测试里了。I是Independent，测试之间不能有依赖，不能要求测试B在测试A之后运行。R是Repeatable，测试在任何环境、任何顺序下跑结果都一样。S是Self-validating，测试结果只有通过和失败两种状态，不能靠人工去看日志判断。T是Timely，测试要及时写，理想情况下先于生产代码。
RIGHT原则的对应关系是：R是Right——测试要测对的东西，别测实现细节；I是Integrated——测试要集成进构建流程，不是可有可无的装饰；G是Guarded——测试要能防止回归；H是Helpful——测试失败时要能快速定位问题；T是Trustworthy——测试本身要可信，不能因为测试代码质量差而让人不敢信它的结果。
我在面试里见过不少候选人，让他解释FIRST能说出一两个单词，但问到“你项目里的测试符不符合Independent原则”就卡壳了。这不是背单词的题，而是理解题。你应该结合自己的项目去讲：比如你把数据库连接Mock掉，就是为了让测试不再依赖外部环境，这就把Repeatable和Independent都落在了实处。
2.3 测试金字塔与Spring Boot测试切片
测试金字塔是面试中另一个绕不开的考点。金字塔自下而上分三层：底层是大量的单元测试，速度快、成本低、定位精准；中间层是少量的集成测试，验证模块之间的协作；顶层是更少量的端到端测试，验证整个系统的核心链路。
面试官通常会追问一句：“你在Spring Boot项目里怎么划分这些层级？”这时候你需要说清楚Spring Boot的测试切片机制。单元测试一般用@WebMvcTest测Controller层、用@MyBatisTest或@JdbcTest测数据访问层、用纯Mockito测试Service层，这些切片测试只加载必要的Bean，启动速度快，适合日常频繁执行。集成测试用@SpringBootTest加载完整上下文，配合@Testcontainers启动真实的中间件，验证跨模块的交互。
这里有个特别容易踩的坑：很多人把@SpringBootTest当作单元测试来用，一个Service方法的测试要加载整个Spring上下文，跑一次要十几秒，整个测试套件跑下来要半小时。这种测试写多了，开发者会越来越不愿意跑测试，最终测试形同虚设。面试的时候，如果你能主动指出这个反模式，并且说明你自己是怎么用测试切片来解决的，会是一个很大的加分项。
3. 实战演示：从零手写一个TDD案例
3.1 场景设定与需求拆解：用户注册接口
纸上谈兵没有意义，我们直接进入实战。面试场景里最常遇到的一个案例是用户注册，需求大概是三条：用户名不能为空且长度3到20位；密码长度不少于8位且必须包含数字和字母；用户名不能与已有用户重复。
很多应聘者拿到这个需求，第一反应是“这有什么好测的，直接写Service不就行了”。但如果你用TDD的思维来拆解，这背后其实隐藏着大量的边界情况。用户名这块：null、空字符串、长度2位、长度3位、长度20位、长度21位。密码这块：纯数字、纯字母、数字加字母但长度不够8位、长度8位满足要求、包含特殊字符但没数字、包含大小写字母但没数字。用户名重复这块：数据库里有同名的、没有同名的、大小写不同的情况要不要算重复。这些用例列出来之后，你会发现“实现一个注册功能”这件事，复杂度全在边界条件里。
我建议你在面试的时候，先把自己列的这些测试用例写在白板或共享文档里，然后再动手写代码。这一步是在向面试官展示你的测试设计能力——只有先想清楚测什么，才能写好测试。
3.2 第一个测试：从红灯开始
按照TDD的规范，我们从第一个测试用例开始：用户名为null时，注册请求应该被拒绝。这里我选择用JUnit 5加AssertJ的写法。
class UserServiceTest { private UserService userService; @BeforeEach void setUp() { UserRepository userRepository = mock(UserRepository.class); userService = new UserService(userRepository); } @Test void shouldRejectUserWhenUsernameIsNull() { RegisterRequest request = new RegisterRequest(null, "abc12345"); assertThatThrownBy(() -> userService.register(request)) .isInstanceOf(IllegalArgumentException.class) .hasMessage("用户名不能为空"); } }这个测试的运行结果必然是红灯，因为UserService这个类还不存在。你注意我的写法：测试里用到了mock(UserRepository.class)，这是把外部依赖先隔离掉，确保我们测的是UserService本身的校验逻辑，而不是数据库的行为。
接下来写最小生产代码让它变绿：
public class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public void register(RegisterRequest request) { if (request.getUsername() == null) { throw new IllegalArgumentException("用户名不能为空"); } } }代码只处理了null这一个分支，测试通过，绿灯。这时候我们进入重构阶段——代码还很简单，没什么可重构的，直接进入下一个测试用例。
3.3 逐步补全用例：红灯与绿灯交替推进
下一个用例：用户名为空字符串时被拒绝。
@Test void shouldRejectUserWhenUsernameIsBlank() { RegisterRequest request = new RegisterRequest(" ", "abc12345"); assertThatThrownBy(() -> userService.register(request)) .isInstanceOf(IllegalArgumentException.class) .hasMessage("用户名不能为空"); }生产代码里，我们用StringUtils.hasText来判断，同时覆盖null和空串两种情况。运行测试，绿灯。注意，这一步隐含了一个重构动作——第一个用例和第二个用例的断言行为统一了，都属于“用户名不能为空”。
继续补用例：用户名长度小于3位时被拒绝。
@Test void shouldRejectUserWhenUsernameLengthLessThan3() { RegisterRequest request = new RegisterRequest("ab", "abc12345"); assertThatThrownBy(() -> userService.register(request)) .isInstanceOf(IllegalArgumentException.class) .hasMessage("用户名长度必须在3到20位之间"); }生产代码：
if (username.length() < 3 || username.length() > 20) { throw new IllegalArgumentException("用户名长度必须在3到20位之间"); }测试通过。随后补上用户名长度超过20位的用例、密码不满足规则的用例、密码长度不足8位的用例、密码缺少数字的用例、密码缺少字母的用例、用户名重复的用例。每一个用例都遵循同样的节奏：先写断言→跑出红灯→写最小代码→跑出绿灯。
等所有用例都通过之后，我们可以再审视一遍生产代码。以用户名校验为例，现在null检查、空串检查、长度检查分散在不同位置，其实可以用一个私有方法封装起来。这就是重构阶段的动作。
public void register(RegisterRequest request) { validateUsername(request.getUsername()); validatePassword(request.getPassword()); ensureUsernameUnique(request.getUsername()); } private void validateUsername(String username) { if (!StringUtils.hasText(username)) { throw new IllegalArgumentException("用户名不能为空"); } if (username.length() < 3 || username.length() > 20) { throw new IllegalArgumentException("用户名长度必须在3到20位之间"); } }重构完再跑一遍全部测试，确保还是绿灯。这个“安全网”的价值在重构时体现得淋漓尽致——你可以放心大胆地调整代码结构，而不用担心悄悄破坏某个行为。
3.4 Spring Boot环境下的测试写法与切片选择
上面的例子是纯单元测试，不依赖Spring容器。但真实的Spring Boot项目里，面试官更希望你展示你会在框架约束下写测试。
如果你要测一个Controller，用@WebMvcTest比较合适。它只加载Web层相关的Bean，不会启动整个Spring上下文，速度很快。示例代码如下：
@WebMvcTest(UserController.class) class UserControllerTest { @Autowired private MockMvc mockMvc; @MockBean private UserService userService; @Test void shouldReturnBadRequestWhenUsernameIsNull() throws Exception { given(userService.register(any(RegisterRequest.class))) .willThrow(new IllegalArgumentException("用户名不能为空")); String requestBody = """ {"username": null, "password": "abc12345"} """; mockMvc.perform(post("/api/users") .contentType(MediaType.APPLICATION_JSON) .content(requestBody)) .andExpect(status().isBadRequest()) .andExpect(jsonPath("$.message").value("用户名不能为空")); } }如果你要测Service层与数据库的真实交互，可以写一个数据库相关的切片测试。假设项目用的是MyBatis：
@MybatisTest @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) class UserMapperTest { @Autowired private UserMapper userMapper; @Test void shouldFindUserByUsername() { userMapper.insert(new User("alice", "abc12345")); Optional<User> user = userMapper.findByUsername("alice"); assertThat(user).isPresent(); assertThat(user.get().getUsername()).isEqualTo("alice"); } }这类测试不会加载Service层，只加载Mapper相关的配置，速度比@SpringBootTest快一些，同时又能验证SQL语句和映射关系是否正确。面试时如果能把这几种测试切片的适用场景分清楚，面试官对你的评价会高很多。
4. 面试高频追问与应答策略
4.1 必问题：Mock和Stub的区别是什么
这个问题可以说是TDD面试里的送分题，但很多人拿不到分，根源在于只知道定义、不知道本质区别。
从目的上说，Stub是测试替身的一种，它提供固定的预设返回值，目的是让被测对象能跑通；Mock不仅提供返回值，还能验证被测对象是否以预期的方式调用了依赖。举例来说，你测试UserService.register方法时，如果只是想让userRepository.findByUsername返回一个存在的用户，那这是Stub；如果你还想验证register方法确实调用了findByUsername并且只调用了一次，那你就需要Mock的verify功能。
UserRepository userRepository = mock(UserRepository.class); given(userRepository.findByUsername("alice")).willReturn(existingUser); // Stub行为 userService.register(request); verify(userRepository, times(1)).findByUsername("alice"); // Mock行为面试的时候，你可以用一句话总结：Stub管“返回什么”，Mock管“怎么被调用”。话虽短，但配合上面的代码示例说出来，比背定义强一百倍。
4.2 “先写测试还是先写实现”的陷阱
这道题看起来答案很明确，肯定是先写测试。但面试官挖的坑在于，他会接着问：“如果需求本身就不明确，你怎么先写测试？”
这是一个非常现实的问题。TDD有一个隐含前提——你至少对行为有一个初步的理解。如果需求完全模糊，你连第一个测试的断言都不知道怎么写，那TDD是推不动的。我的建议是这样的应对思路：先通过测试用例来澄清需求。你可以把自己的理解转化为几个测试用例，跟产品经理或技术负责人对齐：“我理解注册功能应该满足这三个规则，对应这三个测试用例，你们看对吗？”这种沟通方式比纯文字描述需求要精确得多，因为它把模糊的业务描述变成了一组可执行的验证条件。
面试时你可以说：“我并不是机械地先写测试，而是先用测试来固化我对需求的理解。需求不明确的时候，TDD反而是一个很好的澄清工具，因为你的理解如果错了，测试断言就写不对，写代码的时候就会卡住。”
4.3 覆盖率多少才够：从“数字崇拜”到“用例有效性”
覆盖率问题是TDD面试里最容易引发争论的。有人坚持90%以上，有人说80%就行，还有人觉得覆盖率没意义。我个人的看法是，覆盖率是一个必要但不充分的质量指标，面试时你需要展示的是你会“用”覆盖率，而不是“追”覆盖率。
首先要分清楚行覆盖率和分支覆盖率。行覆盖率只统计代码行有没有被执行，分支覆盖率统计每个if/else的两个分支是否都被覆盖过。分支覆盖率比行覆盖率更难达到高数值，但也更有意义。一个行覆盖率95%的Service，分支覆盖率可能只有60%，说明大量异常分支根本没有测试覆盖。
其次，覆盖率数据必须和用例的有效性结合起来看。一个测试如果只断言“方法不抛异常”，那它对代码行为的约束非常弱，即使覆盖率很高，价值也有限。面试时你可以说：“我会关注覆盖率数据，但更关注每个高危分支是否有对应的测试用例。比如注册功能里的用户名重复分支，我必然要有一个用例覆盖到数据库返回已存在用户的情况，这是业务安全的底线。”
最后，关于“团队怎么落实覆盖率门槛”这个问题，你可以提到在CI流水线里配置JaCoCo的检查规则，比如行覆盖率低于75%就构建失败。这体现了你不仅会写测试，还会建设测试基础设施，属于工程素养层面的加分项。
4.4 被问“测试代码需要重构吗”时的深度应答
这个问题考察的是你对测试代码的定位。很多候选人不假思索地回答“需要”，但又说不清楚怎么重构、重构到什么程度，显得很空。
测试代码的重构目标和生产代码不一样。生产代码重构是为了提升可维护性和可扩展性，测试代码重构的核心目标是提升可读性——让后人看到测试的时候，能够快速理解被测类的行为规范。具体来说，我通常会做三件事。第一件是消除重复的测试数据准备，把构造RegisterRequest这类通用对象提取为工厂方法或测试夹具类。第二件是统一断言风格，项目里要么统一用AssertJ的assertThat，要么统一用JUnit的assertEquals，不要混用，减少阅读负担。第三件是给测试方法起有业务含义的名字，比如shouldRejectPasswordWithoutDigit，而不是testPassword01这种毫无信息量的名字。
但这里有个度的问题。测试代码不应该为了追求抽象而变得难以理解。如果一个测试需要你跳三层辅助方法才能看到实际断言，这个测试就已经过度设计了。面试时可以强调：“我会做温和的重构，消除明显重复，但不追求测试代码和生产代码同等程度的架构设计。”
5. 实战踩坑记录与避坑清单
5.1 我在面试中暴露过的三个TDD认知误区
第一次系统性复习TDD的时候，我踩过三个误区，现在回想起来特别值得分享。
第一个误区是以为TDD就是“先写测试再写代码”，忽略了“测试要小步快跑”这个核心。我曾经试图一次把所有测试用例全写出来，然后一次性实现所有生产代码。结果显而易见——测试用例太多，红灯一起亮，根本分不清是哪个逻辑的问题，定位成本极高。后来我改成一次只写一个用例，跑一遍，再继续下一个，效率翻了好几倍。面试时如果面试官要求你现场演示，你千万不要一口气写出一堆测试，而是要展示这种小步推进的节奏感。
第二个误区是把单元测试的粒度搞错了。我曾经为了覆盖率，给一个工具类的私有方法也写了测试，用反射去调用私有方法。这看起来是在追求覆盖率，实际上完全违背了TDD“从行为出发”的原则。私有方法是实现细节，不是行为契约。正确的做法是通过公有方法去覆盖私有方法的逻辑，私有方法本身是否单独测试不重要。面试中被问到测试范围时，这个点很容易变成减分项，因为一旦你迷恋测试私有方法，说明你还没有把TDD的内核理解透。
第三个误区是忽略测试代码的维护。我最早写测试的时候，为了省事，经常把测试数据直接写在方法里，导致大量重复代码，后来需求一变更，改测试的时间和改生产代码的时间一样多。TDD带来的不是“测试写完就完事”，而是“测试和生产代码一样需要持续维护”。这一点和4.4节讲的“测试代码需要重构”是一脉相承的。
5.2 项目里实践TDD的真实困境与应对思路
说句实话，TDD在真实项目里落地非常难，尤其是维护中的老项目。我在自己负责的模块里实践TDD时，遇到过三个特别现实的问题。
第一个问题是历史代码未预留测试点，Service里直接new了依赖对象，根本没法Mock。这个问题的短期解法是引入依赖注入，把new改成构造器或Setter注入；长期解法是逐步用接口替代具体类，让依赖边界清晰化。遇到这类代码，我通常先补一个“特性测试”把当前行为锁住，然后再做重构。
第二个问题是团队的测试基础设施不完善。没有统一的测试基类、没有测试数据库、没有CI里跑测试的流水线，单靠个人推动TDD举步维艰。我的经验是先从自己负责的模块做起，把一套可复用的测试模板搭出来，然后再找机会在技术分享会上推广，让同事看到TDD带来的具体收益——比如上线后线上bug率下降，你会更有说服力。
第三个问题是需求频繁变动，测试也跟着频繁改。面对这种情况，我会在写测试时刻意避免“锁定实现细节”，比如不验证具体调用了哪个私有方法，而是验证方法的返回值和行为结果。这样需求如果只改内部实现，测试就不需要动，TDD的维护成本会大幅下降。面试时讲到这一段，可以先讲自己的困境再讲解法，比纯讲理论可信得多。
5.3 面试时怎么在半小时内展示TDD能力
很多人以为面试官让你手写TDD，就是考察你代码写得对不对。其实反过来，面试官更看重你写代码过程中的思维方式和沟通方式。我总结了几个实战技巧，供你参考。
第一，动手前先把测试用例清单列出来，并跟面试官口头说明。比如“我先列一下测试用例：用户名空值、空串、长度不足、长度超限、密码纯数字、密码纯字母、密码正常、用户名重复”，这句话一出口，面试官就明白你有测试设计的意识。
第二，每一步只做一件事，并且说清楚当前处于红绿重构的哪个阶段。比如“现在我先写用户名为null的用例，预期会失败，因为UserService还没实现”这种边写边说的方式，会给人一种你确实平时就这么工作的感觉。
第三，写完代码后用一两句话总结自己的设计原则。比如“我在校验用户名和密码时统一抛IllegalArgumentException，是为了让错误处理逻辑集中在一个地方，也方便Controller层统一捕获”。这种总结体现了你不仅有TDD的执行力，还有架构思维。
第四，如果面试官让你用纸笔或在线IDE写，不要默不作声地闷头写。每一步都解释一下自己为什么这么写，尤其是Mock的引入位置、断言的选择依据、为什么这里用JUnit5的参数化测试而不是写多个方法。把面试过程变成一次技术分享，远比你默默写出一段完美代码更打动人。
6. 独家心得：从小白到TDD面试高手的进阶路线
6.1 从量变到质变：练TDD最有效的三个小项目
如果你想在面试前把TDD练到“条件反射”的程度，光看书是不够的，必须动手。我推荐三个递进式的小项目，每个都能在一天内完成。
第一个是字符串计算器。需求是支持加法和减法、支持逗号和换行分隔符、支持自定义分隔符。这个项目非常经典，因为它的规则拆解极多，特别适合练“用例设计”。写着写着你就会发现，一行简单的加法函数，竟然能拆出七八个测试用例。第二个是购物车结算功能，涉及折扣、满减、会员价、运费计算。这个项目比字符串计算器复杂的地方在于规则之间有交互，你得学会用测试来约束这些规则组合。第三个是用户注册与登录模块，涉及校验、存储、密码加密、重复检测。做完这个项目，你就能把TDD和Spring Boot的测试切片结合起来，基本属于面试够用级别。
6.2 复盘一次真实的面试对话
去年我模拟过一次TDD相关面试，候选人属于典型的概念熟练但实战生疏。面试官让他用TDD实现一个库存扣减方法，他开口就把TDD的定义念了一遍，然后就开始写生产代码，完全没有先写测试的意识。面试官提醒他“先写测试”之后，他才慌慌张张补了一个测试。整个过程节奏混乱，既没有列用例，也没有明确红绿切换的节点。
这个例子很有代表性。很多候选人不是不懂TDD，而是没有把它变成肌肉记忆。在面对面试压力时，大脑会下意识回到自己最熟悉的路径——“直接写实现”，因为这是大多数程序员日常的工作习惯。要克服这个惯性，没有捷径，只能用反复练习来建立新的神经回路。
如果你也面临同样的问题，我建议你每天抽30分钟，挑一个LeetCode上的算法题，用TDD的方式来实现。注意，不是用TDD去调算法思路——而是把你已知答案的算法，严格按照“红灯→绿灯→重构”的节奏写一遍。练上两周，你会发现先写测试已经变成了一种本能，面试时再也不会脱口而出“要不要先写实现”。
6.3 面试作答的语速与节奏控制
最后分享一个看起来很小、但实际影响很大的细节：面试时讲TDD的语速。技术面试官通常在你回答完之后，还需要一两秒时间去消化你的逻辑。如果你像机关枪一样把概念倒出来，对方很容易跟不上，最终对你形成“背得挺熟”的印象，而不是“理解得很深”。
我的建议是刻意放慢关键节点的语速，尤其是讲解红绿重构循环的时候。每说出一个阶段，停顿一下，观察面试官的反应。如果他在点头，说明你的节奏是对路的；如果他皱眉，你就应该追问一句“这块需要我展开讲吗”。这种互动式作答，比一个人单方面输出要有利得多。
我见过太多候选人，明明技术能力可以，却因为表达节奏太急，让面试官错过关键信息而落选。TDD这个主题尤其适合展现你的逻辑性，千万不要因为语速问题把它讲成一段流水账。
