企业官网建设流程全解析

开头

做过秒杀需求的人都知道，这类业务最折磨人的不是开发，而是验证“到底对不对”。库存只有一百件，十万人同时进来抢，超卖一单就是事故。上线的每一行代码都牵着一堆并发、缓存、幂等、限流的敏感神经。我这些年做过的秒杀类项目里，凡是最后线上出问题的，几乎都能在测试环节找到当初偷懒的影子——要么是代码写完了才补测试，要么是光测了“正常路径”，满脑子只想着怎么抢到，从没想过怎么测失败。

这也是我后来坚定在秒杀系统落测试驱动开发（TDD）的原因。这篇实战笔记不聊高大上的理论，就讲我在同一个项目里，前端用 Jest、后端用 JUnit 跑完整套 TDD 流程的对比和体会。如果你正在纠结要不要在秒杀场景里上 TDD，或者刚入行被“先写测试再写代码”折磨得想摔键盘，这篇文章大概率能帮你少走点弯路。我会把当初踩过的坑、写崩过的用例、以及最后真正见效的写法，都摊开来讲。

1. 秒杀系统对测试的苛刻要求

1.1 秒杀系统到底在“秒”什么

先别急着打开 Jest 和 JUnit 的文档，咱们得先把秒杀系统这个“靶子”立明白。秒杀表面上是一个限时抢购功能，但本质上它是一个对“一致性”和“稳定性”要求极高的写密集型场景。用户看到的是倒计时结束、点击按钮、下单成功或失败，但背后涉及库存预扣、订单生成、支付入口控制、限流降级、防刷风控等一系列环节。

这里面任何一个环节出岔子，结果都不是“代码有 bug”这么轻描淡写。库存超卖，会导致大量用户付款后拿不到货；重复下单，会让订单系统和财务对账乱成一锅粥；接口被刷，会让真正的用户根本挤不进来。这就给测试提出了一个非常现实的需求：你不能只测“功能对不对”，还得测“逻辑在各种极端输入下稳不稳”。

我在项目初期整理需求时做过一个简单的测试点清单，秒杀系统的测试关注点大致是这些：

• 库存扣减是否原子化，并发场景下会不会超卖
• 同一个用户重复点击，系统能不能幂等处理
• 限流规则在流量峰值时能否精准拦截
• 缓存击穿、穿透、雪崩时，数据库能不能扛住
• 倒计时、库存展示、按钮状态等前端交互是否与实际数据一致
• 接口异常、网络超时、重复请求时，用户看到的反馈是否合理

这些点列完之后你再看 TDD，就会发现它特别适合秒杀场景。因为 TDD 讲究“先想清楚预期行为，再写代码”，而秒杀这种逻辑严密、边界场景丰富的业务，恰恰最需要你先把“应该发生什么”想透彻。如果连测试都想不清楚就去写代码，那写出来的代码大概率是靠运气在运行。

1.2 为什么说秒杀测试不能等开发完再做

很多团队的流程是：需求评审 → 前端开发 → 后端开发 → 联调 → 测试 → 上线。测试永远排在最末端，留给测试的时间永远是最少的。这在普通增删改查项目里也许能蒙混过关，但在秒杀项目里就是定时炸弹。

原因很简单：秒杀系统的很多逻辑是“慢一步就变味”。举个例子，库存扣减方案，你是在数据库里做乐观锁更新，还是用 Redis 的 Lua 脚本扣减，还是在应用层加分布式锁？这三种方案在单元测试中体现的路径完全不同。如果你开发完了再补测试，测试只能覆盖你“已经写成这样”的逻辑，而无法验证你“当初是否该这样写”。TDD 迫使你在编码前就把预期行为定下来，相当于给实现方案上了一道“事前约束”。

另一方面，秒杀系统的联调成本极高。前端要等后端接口出来才能测，后端要等数据库数据准备好才能测，两个环节互相等待，最后全堆在测试周期里爆发。TDD 出现在编码阶段之后、联调之前，它让每个模块独立完成自己的行为验证，真正到了联调和提测阶段，基础问题已经被消灭了一大半。我见过太多项目在联调时被一个简单的空指针问题卡住半天，而这个问题如果在写代码时用 TDD 先定义好行为，根本不会出现。

2. TDD 在秒杀系统落地的整体思路

2.1 测试金字塔在秒杀场景的变形

做过测试的人对测试金字塔肯定不陌生：底层是大量单元测试，中间是较少的服务测试，顶层是少量的端到端测试。到了秒杀系统这里，金字塔的形状要稍微改一改，因为秒杀的核心业务逻辑非常集中，而且并发相关的逻辑特别依赖“跨组件协作”。

我实际落地的分层思路是这样的。最底层是单元测试，主要覆盖库存扣减算法、限流算法、幂等判断、优惠金额计算这类的纯逻辑。这些逻辑不依赖外部服务，跑起来飞快，适合用 JUnit 的 JUnit 5 做大规模参数化测试。中间层是组件测试，主要模拟一个请求从 Controller 到 Service 再到 Redis 和数据库的完整链路，这一层用 Mock 工具把外部依赖隔离掉，重点验证业务流程的状态流转。最顶层才是端到端测试，比如用 JMet er 做并发压测，验证真实环境下的表现。

前端这边不太一样，Jest 覆盖的重点更偏向交互逻辑和状态管理。秒杀前端的核心逻辑其实集中在三块：倒计时状态管理、按钮防重复点击、接口返回后的状态切换。对于 Vue 或 React 这类框架项目，Jest 可以配合 Vue Test Utils 或 React Testing Library 写组件测试，把用户的点击行为和页面的渲染结果都断言出来。这样即便后端接口还没联调好，前端也能先通过 mock 数据把自己的行为跑通。

这么分层的核心价值是让测试的执行速度保持“秒级响应”。TDD 的反馈循环讲究快，如果你的单元测试动不动要跑几分钟，你根本坚持不了频繁运行。把纯逻辑的测试放在最底层，让它们保持毫秒级定位问题的速度，是 TDD 能持续跑下去的前提。

2.2 用 Red-Green-Refactor 拆解秒杀需求

TDD 的经典循环是 Red-Green-Refactor，就是先写一个失败的测试，再写最简代码让它通过，最后在测试保护下重构代码。这个循环理解起来很容易，但放到秒杀系统里，需要你有能力把一个大需求拆成一个个“可测试的小步”。

拿库存扣减来举例。新手很容易一上来就想写一个完整的deductStock(userId, skuId, count)方法，然后开始写测试。但这个方法一旦写完，你会发现测试特别难写，因为方法内部可能同时涉及 Redis、数据库、异常回滚、超卖检查。更好的拆法是：

• 先定义“检查库存是否充足”的纯函数，输入是当前库存和扣减数量，输出是布尔值
• 再定义“计算扣减后的剩余库存”的纯函数，输入是当前库存和扣减数量，输出是扣减后的值
• 接着定义“并发环境下保证只成功扣减一次”的逻辑
• 最后才是把 Redis 读取、数据库更新、异常处理串起来的完整流程

每一步都先写失败测试，再写实现代码。这样拆解下来，每一步的行为都很单一，测试也容易写清楚。我在过程中反复体会到的道理是：TDD 表面上是在测代码，实际上是在逼你拆边界。拆不完边界，你的测试和代码都会纠缠成一团。

2.3 先设计用例，再谈测试框架

在动手写 Jest 或 JUnit 之前，我习惯先用一个表格把秒杀核心流程的测试用例设计出来。这个习惯帮我避免了很多“测试写完了但没测到点上”的尴尬。设计用例的核心不是想“写什么代码”，而是想“系统在此时应该呈现什么行为”。

比如针对“用户点击抢购”这个行为，我设计的用例大概长这样：

这个表格列完之后，测试的骨架就已经出来了。你不需要记住每个测试的代码怎么写，只需要保证每个场景在测试代码里都有对应的覆盖。Jest 和 JUnit 在这个环节的角色都只是载体，真正有价值的是把这些场景翻译成可执行的测试代码。

3. Jest 侧实战：前端抢购场景的 TDD

3.1 Jest 在秒杀前端测试中的角色

Jest 是 Facebook 推出的一款 JavaScript 测试框架，它的优点是零配置、自带断言库和 Mock 能力，性能也不错，在 React 和 Vue 项目里都有一席之地。在秒杀系统里，Jest 的角色很纯粹：验证前端所有不依赖真实后端服务的逻辑。

有人觉得前端不需要 TDD，认为页面效果“肉眼能看就行”。但秒杀前端的复杂程度远高于普通页面。倒计时要精确同步服务器时间，用户刷新页面要保证不重置；抢购按钮要防止用户在请求未返回时重复点击，要处理好三种状态（可抢、抢购中、已结束）；库存数字要保证 5 秒内自动更新且不闪烁。这些逻辑不容易通过“肉眼”验证，却没有哪个是 Jest 测不了的。

我在项目里用得最多的三个 Jest 能力：断言和匹配器（对 DOM 状态、组件数据做精确校验）、Mock函数（模拟接口返回、模拟组件事件）、快照测试（对比组件渲染结构的变化）。后两种特别适合秒杀场景，因为秒杀前端状态多，用快照可以一眼看出“代码改动导致页面结构发生意外变化”的问题。

3.2 案例一：倒计时组件的时钟与边界

倒计时是整个秒杀页面最敏感的组件，因为用户能不能抢购，很大程度上依赖倒计时是否精确。开发这个组件时，我用 TDD 从最小行为开始写起。

先写一个失败测试：组件接收一个endTime时间戳，并在渲染后显示剩余时间。测试的写法是：

import { render, screen } from '@testing-library/react'; import Countdown from './Countdown'; describe('Countdown 组件', () => { test('应该显示距离结束时间的剩余时间', () => { const endTime = Math.floor(Date.now() / 1000) + 120; // 2分钟后结束 render(<Countdown endTime={endTime} />); expect(screen.getByText(/01:5[89]/)).toBeTruthy(); }); });

这个测试刚开始肯定会挂，因为组件还没写。接着我写了一个最简单的组件，接收endTime，计算当前时间到结束时间的差值，格式化后插入页面。测试通过后，我又补了一个关键场景：倒计时归零后组件应该显示“已结束”，并且触发结束回调。

test('倒计时归零后应该触发结束回调', () => { const endTime = Math.floor(Date.now() / 1000) + 1; const onFinish = jest.fn(); render(<Countdown endTime={endTime} onFinish={onFinish} />); // 用 jest.useFakeTimers 模拟时间推进 act(() => { jest.advanceTimersByTime(1100); }); expect(screen.getByText(/已结束/)).toBeTruthy(); expect(onFinish).toHaveBeenCalled(); });

写这个测试时最需要注意的坑是“时间依赖”。直接使用真实时间会让测试变得不稳定，比如跑到 59 秒和 00 秒交接时可能产生断言差异。我的解决办法是使用 Jest 的假定时器（Fake Timers），把setInterval和setTimeout都模拟成可控的，这样才能精确验证时间边界。这种控制在真实执行中几乎没法验证，但 TDD 让我在写组件前就把边界情况想清楚了。

3.3 案例二：抢购按钮与接口的 mock 策略

抢购按钮的难点在于状态控制：点击前是“立即抢购”，点击后是“正在抢购”，接口返回后要么变成“已抢购”要么恢复可点击状态。最关键的是，用户连点两次时，系统不能产生两个并发请求。

用 Jest 做这个组件的 TDD 时，最核心的是 Mock 掉接口调用。我把网络请求封装成了一个requestFlashSale函数，在测试里通过jest.mock控制它返回真实的 Promise：

jest.mock('../../api/flashSale', () => ({ requestFlashSale: jest.fn(), })); import { requestFlashSale } from '../../api/flashSale'; test('用户连点两次不会发出两次请求', async () => { let resolveRequest; requestFlashSale.mockReturnValue(new Promise(resolve => { resolveRequest = resolve; })); const handleClick = jest.fn(); render(<FlashSaleButton skuId="123" onClick={handleClick} />); fireEvent.click(screen.getByText('立即抢购')); fireEvent.click(screen.getByText('立即抢购')); expect(requestFlashSale).toHaveBeenCalledTimes(1); });

这个测试的价值在于，它把“防重复请求”这个业务规则直接提炼成了可断言的代码。如果开发时不先写测试，依赖真实的网络请求，你永远也无法在 UI 层面验证“只请求了一次”这个行为。mock 接口的正确姿势是只 mock 应该被 mock 的部分，比如网络层和外部时间，而尽量不 mock 组件内部的业务状态。

这个案例我踩过一个坑：一开始我把整个requestFlashSale都 mock 掉了，导致测试只能验证按钮文案变化，核心的业务请求参数完全没校验。后来调整为让 mock 返回一个手动控制的 Promise，测试随即能校验“第一次点击携带的参数正确”，也能模拟请求失败时按钮恢复可点击，覆盖的范围立刻大了很多。

3.4 Jest 写入真实前端测试的感悟

Jest 侧跑完这些测试之后，我有一个比较深刻的体会：前端 TDD 的真正价值不在 UI 视觉层面，而在“交互状态的确定性”。页面长什么样可以通过肉眼确认，但用户点击后的状态流转是不是符合预期，只有测试能保证。秒杀这种高压力场景，用户的操作行为会被无限放大，连点、刷新、返回、切换网络，任何一个状态没控制好，都会引发用户投诉。

我的建议是，前端团队如果刚开始推行 TDD，可以从交互最复杂的组件入手，比如倒计时、抢购按钮、库存展示。这些组件具备“单一职责、输入多变、状态丰富”的特点，恰恰是 Jest 最擅长验证的内容。先在这些组件上跑通 Red-Green-Refactor 的流程，等团队熟悉了节奏，再逐步扩展到接口层和状态管理层。

4. JUnit 侧实战：库存扣减与幂等的 TDD

4.1 JUnit 在秒杀后端测试中的角色

JUnit 是 Java 生态最老牌的测试框架，目前主流版本是 JUnit 5（也叫 Jupiter）。它不是一个简单的断言库，而是一整套测试模型，支持注解式生命周期管理、参数化测试、嵌套测试、动态测试等能力。在秒杀系统里，JUnit 的角色是守好后端核心逻辑的关卡。

后端代码通常分为 Controller、Service、Repository 三层。JUnit 测试最常见的策略是重点覆盖 Service 层，因为它承载了主要的业务规则。对秒杀系统来说，Service 层的库存扣减、幂等校验、限流判断，每一个都值得写一组专门的测试。

JUnit 5 的注解体系提供了很好的测试组织方式。我习惯用@DisplayName为测试方法标注业务含义，比如@DisplayName("库存充足时扣减成功")，这样测试报告读起来像一份需求文档。再用@Nested把相同模块的测试组织成树状结构，让测试代码的维护成本大幅降低。

4.2 案例一：库存扣减的原子性与并发模拟

库存扣减是秒杀系统最核心的代码，也是超卖问题最容易出现的地方。用 TDD 开发这块时，第一步不是写实现，而是写一个能描述“正确行为”的测试。

我最初的测试场景是：库存为 1 时，两个并发请求同时扣减，最终只有一个成功。这个测试在 JUnit 里实现如下思路：

class DeductStockServiceTest { @Test @DisplayName("并发扣减同一库存不会出现超卖") void concurrentDeductShouldNotOversell() throws Exception { DeductStockService service = new DeductStockService(new InMemoryStockRepository()); int threadCount = 100; int stock = 10; service.seedStock(stock); ExecutorService executor = Executors.newFixedThreadPool(threadCount); CountDownLatch start = new CountDownLatch(1); List<Future<DeductResult>> results = new ArrayList<>(); for (int i = 0; i < threadCount; i++) { Future<DeductResult> future = executor.submit(() -> { start.await(); return service.deduct(1L); }); results.add(future); } start.countDown(); long successCount = 0; for (Future<DeductResult> future : results) { if (future.get().isSuccess()) successCount++; } assertThat(successCount).isEqualTo(stock); assertThat(service.getRemainingStock()).isZero(); } }

写这个测试时，实现代码还没有。如果直接用真实数据库，测试会变成一个集成测试，速度慢且不稳定。我用了内存仓库（InMemoryStockRepository）模拟库存存储，让并发测试可以快速运行。真正的数据库更新逻辑留在另一组集成测试里验证，这样单元测试和集成测试各司其职。

这个测试的意义在于，它不仅验证了“代码正确”，还强制你把“并发安全”作为一个显式的设计约束。当你先写完这个测试，你的实现方案就会天然地往乐观锁、原子更新或分布式锁方向思考。如果先写代码再补测试，很可能你写出来的代码根本不是并发安全的，测试只是用来给 bug 盖章。

4.3 案例二：幂等控制与防重复下单

另一个容易被忽略但极其重要的后端场景是幂等。秒杀接口被用户连点、被网络重发、被恶意脚本重复请求，都是常态。如果后端不做幂等控制，用户的重复点击就会产生多个订单，导致库存扣减和订单数据不一致。

同样的 TDD 思路，先写测试定义幂等行为。我的测试脚本是：同一个用户和同一个商品，调用两次提交订单接口，第二次调用应该被幂等拦截，并且最终的订单数量为 1。

@ParameterizedTest @ValueSource(strings = {"OPTIMISTIC_LOCK", "TOKEN", "UNIQUE_KEY"}) @DisplayName("不同幂等方案都能防止重复下单") void repeatSubmitShouldBeIntercepted(String strategy) { FlashSaleService service = new FlashSaleService(strategy, new InMemoryOrderRepository()); Long userId = 1L; Long skuId = 100L; SubmitResult first = service.submitOrder(userId, skuId); SubmitResult second = service.submitOrder(userId, skuId); assertThat(first.isSuccess()).isTrue(); assertThat(second.isSuccess()).isFalse(); assertThat(service.countOrders(userId, skuId)).isEqualTo(1); }

这个测试比较有意思的一点是，我用@ParameterizedTest把三种幂等实现通通跑了一遍。可以看出同一份测试代码既能驱动出一种实现，也能同时约束几种实现的行为一致性。实际项目里，我最后选择了“唯一键 + 业务状态判断”的方案，因为它在性能和可靠性之间比较均衡。

这里我特别想强调一个 JUnit 容易踩的坑：同步测试方法默认不是线程安全的。如果你在测试里同时操作同一个共享状态，比如一个静态变量或同一个内存仓库实例，ForkJoinPool 并发执行时很容易互相污染。后来我把并发相关测试都加上了@Execution(CONCURRENT)但把共享仓库改成每次新建实例，才彻底解决。

4.4 JUnit 参数化测试在流程校验中的妙用

秒杀系统的业务流程分支很多，比如用户是否登录、是否在活动时间内、是否超过限购数量、活动是否已结束。如果为每种情况单独写一个测试方法，测试代码会非常冗余。JUnit 5 的参数化测试是解决这个问题的利器。

我常把“异常流程”集中写成一个参数化测试类，每一种情况对应一行测试参数。举个例子：

@ParameterizedTest @CsvSource({ "NOT_LOGIN, 应该提示先登录", "NOT_IN_TIME, 应该提示活动未开始", "OVER_LIMIT, 应该提示超过限购数量", "STOCK_EMPTY, 应该提示库存不足", "REPEATED_SUBMIT, 应该提示不能重复提交", }) void submitOrderShouldReturnProperMessage(OrderValidateResult result, String expectedMessage) { String actual = flashSaleService.validateAndSubmit(result); assertTrue(actual.contains(expectedMessage)); }

这样设计的好处是，当产品新增一种异常场景时，我只需要在@CsvSource里增加一行测试参数，同时由测试驱动你去修改实现代码。TDD 里有个原则叫“测试是活文档”，参数化测试把这个特点发挥到了极致。如果你在代码评审时看到一堆重复的测试方法，不如看看能不能改成参数化测试，往往能减少一半代码量。

5. Jest 与 JUnit 在多维度下的正面交锋

5.1 各自擅长的战场

很多团队把 Jest 和 JUnit 放在一起对比，其实两者的战场天然不同。Jest 的核心战场在 JavaScript/TypeScript 前端，或者 Node.js 后端服务；JUnit 的核心战场在 Java/Kotlin 后端服务。如果你的技术栈是“React/Vue 前端 + Spring Boot 后端”，那结论几乎是一边倒的：前端写 Jest，后端写 JUnit，互不冲突。

但从“实战对比”的角度看，两者有几个可以交锋的维度。第一个是安装配置成本，Jest 开箱即用，在 Vite 或 Create React App 项目的辅助下几乎零配置；JUnit 5 需要引入spring-boot-starter-test或手动依赖，配置项也多一些，比如 surefire 插件版本、断言库的选择。第二个是测试执行速度，Jest 通过 worker 并行执行，速度非常快；JUnit 5 同样可以并行，但 Java 的启动和编译开销明显更高。

第三个维度是 Mock 的灵活性。Jest 的jest.mock和jest.fn是 JavaScript 原生实现，在模块加载阶段就能替换依赖，非常灵活；JUnit 侧常用的 Mockito 通过动态代理实现 Mock，对 final 类、静态方法的模拟能力相对弱一些，需要额外引入 mockito-inline。这会导致同样复杂的 mock 场景，前端写起来更顺畅。

5.2 测试速度与反馈循环的差异

TDD 特别依赖“短反馈循环”。我从实操角度总结了两者在这个维度上的表现差异：

这里要诚实说一句：JUnit 的反馈速度不如 Jest 是客观事实，但它在后端场景里的价值在于“能测到更接近系统的行为”。单测再快，如果测不到业务核心逻辑，也没法覆盖“真金白银”的风险。我在实践中通常用 Jest 保前端交互，用 JUnit 保后端核心，两者互补，而不是非要比个高下。

5.3 团队选型时的协作成本

从团队协作角度，两者对人员能力和开发习惯的要求差别很大。Jest 生态里常见的做法是“测试和组件放在同一目录”，或者用__tests__文件夹集中管理，团队习惯容易养成。JUnit 侧，因为 Spring 项目的依赖注入和上下文启动比较复杂，测试的编写门槛更高，团队里需要有人能负责测试基础设施（基类、注解、测试容器）的搭建。

我们项目里实际的做法是：前端测试由前端开发直接维护，后端 JUnit 测试由后端开发负责，测试基建（比如统一的测试基类、覆盖率框架、CI 流水线配 置）由资深的测试效率和后端开发一起维护。这样分工下，Jest 和 JUnit 各管一摊，TDD 流程可以见缝插针地推进。

回头想，如果团队规模小，只有一两个人维护整个秒杀系统，我会建议优先后端 JUnit，因为库存、订单、幂等这些核心资产的风险更大，后端保住了，系统就稳了。等后端稳定了，再把 Jest 补到前端做交互保障。

6. 秒杀 TDD 避坑记录：我的独家经验

6.1 并发问题单测测不出来，怎么办

这是我在秒杀项目里收到最多的疑问：“JUnit 的并发测试能模拟真实高并发吗？”坦白说，单测里用线程池模拟的并发和真实流量高峰完全是两回事。单测只能验证“代码在竞争条件下逻辑是否正确”，无法验证“JVM 线程调度、网络延迟、数据库连接池耗尽”带来的真实问题。

所以我的经验是：并发正确性靠单测守底线，容量和性能靠压测验证上线。单测的重点放在“断言逻辑正确”，比如扣减不能超卖、重复提交不能成功；压测再放到集成环境里，用 JMet er 或 Gatling 扫描真实链路的瓶颈。两者分担不同的责任，千万不要因为单测写了并发模拟就放松压测准备。

6.2 覆盖率数字的几个坑

覆盖率是 TDD 落地时最容易让人产生幻觉的指标。我见过不少团队把“行覆盖率必须达到 80%”写进开发规范，结果为了数字达标，写了一堆只调用不判断的测试，覆盖率看着上去了，该测的业务逻辑反而没人管。秒杀项目里这更是大忌，因为核心风险往往集中在几行关键逻辑上。

建议把覆盖率目标拆成两个维度：行覆盖率和分支覆盖率。行覆盖率代表“代码被跑过多少”，分支覆盖率代表“每个 if/else 分支是否都被覆盖”。对秒杀系统来说，分支覆盖率更能反映测试质量，因为库存不足、重复提交、未到时间这些分支如果不测，系统上线后早晚出事故。可以利用 JaCoCo（后端）和 Jest Coverage（前端）智能地输出分支覆盖数据。

6.3 如何让 TDD 节奏在迭代压力下存活

很多团队推行 TDD 时死在“没时间”上。需求排期紧，产品催上线，测试自然成了第一个被砍的环节。我的应对经验是：缩短 TDD 的“单元步长”，不要想着一次性把整个功能都测完，而是把功能拆成最小可验证的切片，一个切片一个循环地走。

拿库存扣减来说，不要一开始就写一个“完整服务方法”的测试，而是先写“扣减方法”的测试，再写“更新数据库”的测试，最后写“返回结果给调用方”的测试。每一步 5-10 分钟就能完成，测试从红到绿的反馈也很快。这样团队既有写测试的实感，又不至于因为长时间看不到功能进展而焦虑。压力越大，越要把 TDD 拆得细，因为细才可控，可控才不至于返工。

6.4 秒杀专项测试的兜底组合拳

最后分享一套我目前比较顺手的秒杀测试兜底组合。这个组合不是一步到位设计出来的，是踩了数次事故后一点点拼出来的，分享出来供你参考：

• 单元测试层：JUnit 5 覆盖库存扣减、幂等、限流等纯逻辑，追求分支覆盖率
• 前端组件层：Jest 覆盖倒计时、连点、异常提示等交互状态，快照测试防止结构误改
• 集成测试层：Testcontainers 启动 Redis 和 MySQL，验证真实组件组合后的行为
• 接口自动化层：Postman/Newman 或 REST Assured 跑关键接口列表，保证每个迭代没有破坏既有接口
• 压测层：JMeter 至少执行一次全链路抢购压测，验证性能和安全库存水位

这一套组合拳的好处是：单测保证“对”，压测保证“快”，组件测试保证“稳”，接口自动化保证“兼容”。少了任何一环，秒杀系统都可能在外界压力下暴露出难以预料的缺陷。

回到标题本身，Jest 和 JUnit 不是互相排斥的替代品，而是各自守护一块阵地的队友。前端交互和状态流转交给 Jest，后端核心逻辑和并发正确性交给 JUnit，两边跑通 TDD 的节奏后，秒杀系统的整体工程质量会有非常明显的提升。如果你正准备在项目里落地 TDD，不用等团队都准备好，挑一个最核心的模块，用最小的测试骨架开始写，先跑通一个小循环，你会发现，测试驱动开发这件事，实际上是在驱动你把需求想清楚，顺带把代码写得更干净。