说实话我一直是个测试拖延症患者。每次写完功能代码心里都清楚应该补测试但手就是敲不下去。想着这个功能这么简单不会有问题的然后安慰自己等有空了再补。结果呢技术债越积越多每次改代码都心惊胆战。上个月开始用Claude Code的/test功能情况完全变了。以前写10个测试用例要1小时现在10分钟搞定。这篇文章我想聊聊/test到底能做什么、不能做什么以及为什么它改变了我对写测试的态度。为什么我们不爱写测试在讲工具之前先聊聊痛点。我自己总结不写测试的原因大概是这几个1. 启动成本太高你要先理解代码逻辑然后想这个函数可能有哪些输入再考虑边界情况是什么最后还要按测试框架的语法写。有时候写测试比写功能代码还费脑子。2. 不知道测什么特别是给遗留代码补测试看着那一堆业务逻辑根本不知道从哪里下手。测主干流程边界条件异常处理感觉样样都要测但又不知道优先级。3. 写了也不知道对不对测试代码也是代码也会写错。我经常遇到测试通过了但功能其实有问题或者测试一直失败但查了半天发现是测试写错了。4. 正反馈太慢写功能代码跑起来看到效果是有即时满足感的。但写测试吭哧吭哧写半天只是确认代码没问题心理上没什么获得感。这些痛点叠加起来就形成了我知道该写但就是不写的怪圈。/test的核心能力Claude Code的/testskill核心能力就一句话根据你的代码自动生成测试用例草稿。但它不是简单的代码复制粘贴而是会做这几件事1. 分析代码逻辑分支比如这个函数def calculate_discount(price, user_type, coupon_codeNone): if price 0: raise ValueError(价格必须大于0) if user_type vip: price * 0.8 elif user_type svip: price * 0.7 if coupon_code: if coupon_code.startswith(SAVE): price - 10 return max(price, 0)/test会分析出异常分支price 0、条件分支三种用户类型、嵌套条件优惠券前缀、边界处理max兜底。然后针对每个分支生成测试用例。2. 识别边界条件和异常情况人写测试有个通病只测正常情况。/test会自动识别输入参数的边界值、条件判断的边界、异常抛出场景、空值处理——这些我们很容易漏掉的点。3. 适配项目测试框架它会检测你项目里用的什么框架pytest、unittest、jest等然后用对应的语法生成直接融入项目。一个真实案例我在写一个CSV处理函数def process_csv(file_path, encodingutf-8, skip_errorsTrue): results [] with open(file_path, r, encodingencoding) as f: reader csv.DictReader(f) for row_num, row in enumerate(reader, start2): try: cleaned {k.strip(): (v.strip() if v else None) for k, v in row.items()} if email in cleaned and not in cleaned[email]: raise ValueError(f第{row_num}行邮箱格式错误) results.append(cleaned) except Exception as e: if not skip_errors: raise logger.warning(f第{row_num}行处理失败: {e}) return results要考虑的场景很多正常文件、不同编码、空文件、只有header、包含错误格式的行、字段缺失、邮箱验证等。我跑/test它15秒生成了12个测试用例覆盖所有场景。更惊喜的是它检测到我用了logger自动加了mock验证。这个细节我自己写的时候很可能会忘。它的局限我也要诚实说当然/test不是银弹。1. 不理解业务语义它能分析代码逻辑但不知道你的业务是什么意思。比如转账函数它不会测 from_account和to_account是同一个账户 的业务规则——因为从代码逻辑看这两个参数没有关联约束。2. 复杂依赖需要手动处理如果你的代码依赖数据库、Redis、第三方API/test生成的测试可能会直接调用真实依赖而不是mock。需要你自己加上unittest.mock的处理。3. 测试数据需调整生成的测试数据往往是示意性的可能不符合你的业务规则比如邮箱格式、密码强度需要根据实际情况调整。我的使用 workflow第一步写功能代码暂时不写测试第二步功能跑通后跑/test生成第一轮测试覆盖率通常在60-70%第三步人工review——删掉无意义的、调整边界值、补充漏掉的场景、加上mock第四步跑测试修复失败项第五步看覆盖率报告查漏补缺整个过程下来写测试的时间从1小时压缩到10-15分钟覆盖率反而更高。写在最后用/test这段时间我对写测试的态度变了。以前我觉得测试是负担是为了覆盖率而写的形式主义。现在我觉得测试是安全网——有了它我敢重构代码、敢升级依赖、敢在周五下午部署。/test没有改变测试的价值它只是把写测试的成本降到了我能接受的程度。如果你也和我一样明明知道该写测试但就是拖延不妨试试这个工具。它不会替你完成所有工作但它能帮你开个头——而很多时候开头是最难的。**你现在写测试吗是手写还是用工具辅助有什么心得。关注我继续给大家推荐免费且实用的skill。