秒杀系统的测试报告全绿线上却超卖了38单——这是我第一次把TDD测试驱动开发认真引入高并发项目时遇到的事。不是TDD没用是我把测试写错了地方。后来我把同一套秒杀核心逻辑分别用Jest和JUnit从头到尾按TDD重写了一遍对比出来的差异远比“JS用Jest、Java用JUnit”这句废话深刻得多。这篇就聊聊我在秒杀场景下用这两个框架实测对比的真实体感包括哪些用例该写、哪些不该写、以及为什么你的并发测试大概率在自欺欺人。1. 秒杀系统里真正难测的不是“功能对错”而是“那一瞬间的秩序”很多团队拿到秒杀需求第一反应是把接口调通、把库存扣减逻辑写完然后压测一把看着QPS数字发朋友圈。但秒杀系统最难的地方不是吞吐量是极端并发下业务规则仍然成立。TDD在这类场景的价值不是让你写出更多测试而是逼你先把“规则”用代码表达清楚。1.1 为什么普通业务测试在秒杀面前几乎失效普通电商下单你mock一个用户、mock一件商品验证“下单成功、库存减一”测试就过了。但秒杀的语义是10000个人抢10件商品最终必须恰好10个人成功其余9990个人收到“已售罄”而且每个人的扣减行为不能互相覆盖。这意味着你不能只测“正确路径”你得测“边界竞争”——同一时刻多个请求读到同一个库存快照怎么办扣减操作是先查再写还是原子自减用户重复请求两次算不算两单传统单元测试里你mock掉数据库、mock掉Redis测出来的“通过”往往只是自洽不是正确。我在Jest里很快就发现了这个问题测试环境里一切都是同步的、顺序的你根本复现不出生产环境里那几毫秒的竞态窗口。1.2 三个最容易踩的测试盲区超卖、重复支付、缓存击穿先说超卖。最经典的错误写法是先SELECT库存再UPDATE库存两个操作之间隔着网络延迟和线程调度10个并发请求读到的库存都是1然后全部执行UPDATE库存变成负数。TDD要做的就是把这个bug变成测试用例写一个测试启动20个并发扣减断言库存最终不小于0。再说重复支付。秒杀场景用户会疯狂点击“立即抢购”前端可以防抖后端必须幂等。你的测试得验证“同一个用户ID、同一个活动ID第二次请求必须被拒绝”而且拒绝必须发生在事务提交之前。这个逻辑如果放在代码review阶段靠人眼发现基本等于裸奔。最后是缓存击穿。秒杀的热点key在Redis里过期瞬间大量请求穿透到数据库。TDD视角下你要测试的是“当缓存未命中时是否只有一个线程回源数据库”。但这里有个残酷的事实单测里你根本测不出线程数。你得靠集成测试或专门的并发测试工具去补位。2. 先别急着写并发用例TDD的正确起点是那个纯函数很多人听说TDD就兴奋立刻开始写并发测试、模拟高并发结果发现测试本身比业务代码还难写而且每次跑结果还不一样。我踩了这个坑之后才明白并发不是TDD的起点纯函数才是。2.1 从“库存扣减”这个纯函数开始写第一个失败用例TDD的红绿循环在秒杀系统里同样适用但你得先找到那个“纯”的核。所谓纯函数就是同样的输入必然得到同样的输出不依赖外部状态。库存扣减看起来不纯——它要查库存、改库存——但你可以把决策逻辑提取出来// stockService.ts export function canDeduct(currentStock: number, requestedQty: number, limitPerUser: number, userPurchased: number): boolean { return currentStock requestedQty userPurchased requestedQty limitPerUser; }这个函数不碰数据库、不碰Redis纯粹根据传入的库存快照和用户已购数量做判断。对这样的函数做TDD用例极其清晰库存充足、未超限 → 返回true库存不足 → 返回false用户已购数量加上本次请求超过限购 → 返回false库存刚好等于请求数量 → 返回true写第一个用例时它会失败因为函数还不存在你花30秒实现用例变绿。这个过程看起来简单但它建立了测试的地基——规则本身被测试固化了后续谁改逻辑测试立刻报警。2.2 当设计模式遇到TDD依赖倒置让Mock变得顺理成章测试库存扣减服务时必然要接触数据库、缓存、消息队列。如果这些外部依赖在测试里真实存在你的测试速度会慢到让人放弃。TDD逼你反向思考为了让服务可测试你必须让它面向接口而不面向实现。用Java写就是依赖倒置public class StockDeductService { private final StockRepository stockRepository; private final RedisClient redisClient; public StockDeductService(StockRepository stockRepository, RedisClient redisClient) { this.stockRepository stockRepository; this.redisClient redisClient; } public DeductResult deduct(String userId, String activityId, int quantity) { int currentStock stockRepository.getStock(activityId); int userPurchased redisClient.getUserPurchased(userId, activityId); if (!StockRule.canDeduct(currentStock, quantity, 2, userPurchased)) { return DeductResult.fail(库存不足或超出限购); } boolean updated stockRepository.deductWithVersion(activityId, quantity); return updated ? DeductResult.success() : DeductResult.fail(库存已被抢完); } }注意这里的deductWithVersion——不是简单的UPDATE stock stock - 1而是带版本号或条件更新WHERE stock quantity这是防超卖的原子性保证。这个设计不是凭空来的是TDD的红灯逼你思考“既然会出现并发扣减那么谁保证原子性答案是一个数据库原子操作而不是锁一段代码。”2.3 测试金字塔在秒杀场景下的变形单测、集成、契约秒杀系统的测试不应该只有单元测试。我的分层做法是单元测试覆盖纯逻辑比如限购规则、库存判断、幂等key生成规则。用Jest或JUnit写速度快毫秒级。集成测试真的启动一个数据库测试库验证deductWithVersion的SQL在并发下不超卖。这层用JUnit Testcontainers或者Jest testcontainers-node。契约测试前后端分离的团队前端要mock后端接口后端要保证接口返回结构稳定。用Pact这类工具Jest和JUnit都有适配器。很多秒杀项目只做了第一层压测环境又不会自动跑于是超卖问题一路裸奔到线上。3. Jest实战用fake timers和mock模块还原抢购现场Jest是前端和Node.js生态里最常见的测试框架我对它的定位是**“业务逻辑的快速验证器”**。它运行在Node环境测试速度快Mock能力极强适合重构频繁的前端代码和BFF层。3.1 Jest的领域优势前端与Node.js后端的同构测试如果你的秒杀系统用了Node.js写BFF层——负责聚合商品详情、校验用户登录态、转发下单请求——那么Jest是唯一的选择因为你可以直接require真实的BFF代码而不需要起一个HTTP服务。Jest的模块mock机制可以轻松隔离外部依赖// orderService.test.js const orderService require(../orderService); const stockClient require(../stockClient); jest.mock(../stockClient, () ({ deductStock: jest.fn() })); describe(秒杀下单服务, () { beforeEach(() { stockClient.deductStock.mockReset(); }); test(同一用户重复请求只能成功一次, async () { stockClient.deductStock.mockResolvedValue(true); const req { userId: u1, activityId: a1, quantity: 1 }; const first await orderService.createSeckillOrder(req); const second await orderService.createSeckillOrder(req); expect(first.success).toBe(true); expect(second.success).toBe(false); expect(second.code).toBe(REPEAT_REQUEST); expect(stockClient.deductStock).toHaveBeenCalledTimes(1); }); });3.2 一个完整的库存扣减逻辑TDD过程Jest代码我拿秒杀系统的库存预扣模块举例。假设用一个Redis的Lua脚本原子扣减库存Node端封装了一个redisStockStore。TDD的第一步不是写这个封装而是写接口的失败用例// redisStockStore.test.js const RedisStockStore require(../redisStockStore); describe(Redis库存原子扣减, () { let store; beforeEach(() { store new RedisStockStore({ host: 127.0.0.1, port: 6379, db: 15 }); }); afterEach(async () { await store.flushAll(); }); test(库存充足时扣减成功且返回剩余库存, async () { await store.setStock(a1, 100); const result await store.deduct(a1, 3); expect(result.success).toBe(true); expect(result.remaining).toBe(97); }); test(库存不足时扣减失败且库存不变, async () { await store.setStock(a1, 2); const result await store.deduct(a1, 3); expect(result.success).toBe(false); expect(result.remaining).toBe(2); }); test(并发扣减不超卖, async () { await store.setStock(a1, 10); const results await Promise.all( Array.from({ length: 20 }, (_, i) store.deduct(a1, 1)) ); const successCount results.filter(r r.success).length; expect(successCount).toBe(10); expect(results.filter(r !r.success).length).toBe(10); }); });第三个用例是秒杀测试的灵魂——它不需要真实并发只要你的Lua脚本是原子的Promise.all必须恰好10个成功。如果实现用了先get再set的非原子方案这个用例会随机失败而且大概率在9到11之间飘忽不定。这就是TDD给你抓出来的第一个真实bug。那时候我写的Lua长这样的原子版if (tonumber(redis.call(get, KEYS[1])) tonumber(ARGV[1])) then return redis.call(decrby, KEYS[1], ARGV[1]) else return -1 end非原子版本就是一个get加一个set并发下必出超卖。Jest在单测里没法制造两个请求真正同时进入Redis但你能通过Promise.all让Node的事件循环快速连续发起多个异步命令只要Lua脚本的原子性是对的结果永远是确定的。3.3 Jest在秒杀场景的边界并发模拟是短板Jest的短板在于它是单进程、事件循环模型无法模拟真正的多线程竞争。你的JS代码里如果用了worker_threads做并行扣减Jest默认是测不到的。另外Jest的fake timers虽然能帮你模拟时间窗口——比如测试“活动10:00开始9:59请求被拒绝”但它模拟不了网络抖动、连接池耗尽这类基础设施问题。所以我对Jest在秒杀场景的定位很明确它负责业务规则的确定性验证不负责并发正确性的最终证明。4. JUnit实战从原子性断言到真实并发压力Java服务端做秒杀JUnit 5基本是事实标准。相比JestJUnit在秒杀场景的核心优势不是写测试的体验而是它天然活在JVM的多线程世界里你真的可以在测试里起线程、搞并发、验证Shared State。4.1 JUnit 5 Mockito服务层的TDD写法和依赖隔离JUnit 5配合Mockito做依赖隔离写起来比Jest的模块mock更显“工程化”。秒杀的活动服务层通常依赖用户服务、库存服务、订单服务测试时用Mock注入依赖专注测业务编排逻辑ExtendWith(MockitoExtension.class) class SeckillActivityServiceTest { Mock StockService stockService; Mock OrderRepository orderRepository; Mock UserLimitService userLimitService; InjectMocks SeckillActivityService service; Test void 用户已购数量未超限时允许下单() { when(userLimitService.getPurchasedCount(u1, a1)).thenReturn(0); when(stockService.deductWithVersion(a1, 1)).thenReturn(true); SeckillResult result service.createOrder(u1, a1, 1); assertTrue(result.isSuccess()); verify(orderRepository).create(any(SeckillOrder.class)); } Test void 用户已购数量达到限购时拒绝下单() { when(userLimitService.getPurchasedCount(u1, a1)).thenReturn(2); SeckillResult result service.createOrder(u1, a1, 1); assertFalse(result.isSuccess()); assertEquals(LIMIT_EXCEEDED, result.getCode()); verify(stockService, never()).deductWithVersion(any(), any()); } }这两个用例的价值在于明确服务层的边界判断限购在扣减库存之前。如果你把限购判断放到扣减之后才发现超限那库存已经被扣了只能走退款补偿流程。TDD的红灯会让你提前确定这个顺序。4.2 用CountDownLatch和ExecutorService模拟并发扣减真正让我对JUnit产生好感的是它在集成测试里模拟并发的成熟度。Jest的Promise.all在Node里只是异步交叉JUnit的并发测试是真真切切的多线程竞争共享内存。模拟秒杀场景的经典做法Test void 并发扣减不超卖() throws InterruptedException { int threadCount 100; int stock 10; stockRepository.resetStock(activityId, stock); ExecutorService executor Executors.newFixedThreadPool(threadCount); CountDownLatch readyLatch new CountDownLatch(threadCount); CountDownLatch startLatch new CountDownLatch(1); CountDownLatch doneLatch new CountDownLatch(threadCount); ListFutureBoolean results new ArrayList(); for (int i 0; i threadCount; i) { final String userId user_ i; results.add(executor.submit(() - { readyLatch.countDown(); startLatch.await(); boolean ok stockService.deductWithVersion(activityId, 1); doneLatch.countDown(); return ok; })); } readyLatch.await(); long start System.nanoTime(); startLatch.countDown(); doneLatch.await(); long costMs TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start); long successCount results.stream().filter(f - { try { return f.get(); } catch (Exception e) { return false; } }).count(); assertEquals(10, successCount); assertEquals(0, stockRepository.getStock(activityId)); executor.shutdownNow(); }这个测试有几个关键细节CountDownLatch(1)的startLatch保证100个线程尽可能同时出发不是依次排队扣减否则并发效果大打折扣。库存断言必须查库你不能只断言successCount10还得查数据库确认库存真的归零防止内存里的乐观状态骗人。最后加一个执行耗时断言个人经验秒杀单次扣减超过50ms基本就out了但网络环境不同不建议写死可以用来做性能回归基线。4.3 断言的艺术JUnit里如何验证“只扣了一次”秒杀系统最常见的bug是同一个用户的重复请求创建了多笔订单。你可以用Mockito的verify精确验证调用次数Test void 同一用户重复下单只扣减一次库存() { when(userLimitService.getPurchasedCount(u1, a1)).thenReturn(0); when(stockService.deductWithVersion(a1, 1)).thenReturn(true); service.createOrder(u1, a1, 1); service.createOrder(u1, a1, 1); verify(stockService, times(1)).deductWithVersion(a1, 1); verify(orderRepository, times(1)).create(any(SeckillOrder.class)); }但这个用例有个前提限购判断逻辑里必须从“用户已购数量”这个外部状态读取数据如果getPurchasedCount第一次返回0、第二次还是返回0那是因为你的mock没有按调用顺序返回不同值。这种时候你要用thenReturn(0, 1)模拟第一次查无记录、第二次已购买1件。还有个更隐蔽的坑只要服务方法不是原子的两次请求可能同时读到getPurchasedCount0。verify次数只能证明方法调了几次不能证明并发下没有竞态。要彻底验证你还得回到4.2那种多线程集成测试配合数据库唯一约束如(user_id, activity_id)唯一索引来兜底。5. 对比后的真心话选Jest还是JUnit本质是选测试重心很多人问“秒杀系统到底该用Jest还是JUnit”我的答案可能会让一些人不舒服真正决定选型的不是你更喜欢哪种语法而是你的系统重心长在哪里。后端是Java、用了Spring Boot那JUnit 5就是你的主战场写并发集成测试、验证数据库层原子性、搞Testcontainers都顺手。前端是React/VueBFF层是Node.js那Jest就是你的主战场它能把组件测试、Mock Service Worker、接口契约测试一揽子接住。最怕的是两边都想测结果两边都只测了一半。我见过一个项目Java后端用JUnit测了服务层的if-else分支Node前端用Jest测了按钮能不能点唯独没人测库存扣减的原子性。框架选得没问题测试重心完全跑偏了。5.1 一张表看清差异维度JestJUnit 5适用语言JavaScript / TypeScriptJava / Kotlin典型战场前端组件、BFF层、Node服务Spring Boot后端、微服务并发模拟能力弱单线程事件循环强真实多线程数据库集成测试可用testcontainers-node生态一般Testcontainers成熟度高Mock机制jest.mock模块级mock灵活但容易mock过头Mockito InjectMocks走依赖注入更规范适合在TDD中测什么业务规则、状态流转、接口返回数据一致性、并发竞争、事务边界这个表不是想说JUnit比Jest强而是想说并发问题的最终裁判必须落在“能真正起多线程的那个框架”里。Jest在秒杀场景里如果只是测Promise.all可能给你虚假的安全感。5.2 双轨并行的工程实践建议如果项目正好是“前端Java后端”的典型秒杀架构我建议TDD分两轨走一轨是Jest负责前端和BFF层的“行为规则”。比如倒计时结束后才显示购买按钮、抢购成功后按钮立即置灰、轮询订单状态的接口返回什么才跳转支付页。这些用例多而快适合Jest。另一轨是JUnit负责后端核心的“数据规则”。比如库存扣减原子性、订单幂等性、事务回滚边界、超卖拦截。这些用例重、慢但必须存在。个人经验是秒杀系统的TDD覆盖率不需要追求100%但核心链路的核心规则必须全部覆盖。我通常把“库存”“订单”“支付回调”这三个模块的TDD用例列为发布阻断项——任何一个挂了都不能发版。Jest和JUnit不是竞争对手它们各自守着自己那道闸门。真正该测的地方没测那才是事故的开始。