说实话，我一直是个"测试拖延症患者"。

每次写完功能代码，心里都清楚应该补测试，但手就是敲不下去。想着"这个功能这么简单，不会有问题的"，然后安慰自己"等有空了再补"。结果呢？技术债越积越多，每次改代码都心惊胆战。

上个月开始用Claude Code的 /test 功能，情况完全变了。以前写10个测试用例要1小时，现在10分钟搞定。

这篇文章，我想聊聊 /test 到底能做什么、不能做什么，以及为什么它改变了我对写测试的态度。

---

为什么我们不爱写测试？

在讲工具之前，先聊聊痛点。

我自己总结不写测试的原因，大概是这几个：

1. 启动成本太高

你要先理解代码逻辑，然后想"这个函数可能有哪些输入"，再考虑"边界情况是什么"，最后还要按测试框架的语法写。有时候写测试比写功能代码还费脑子。

2. 不知道测什么

特别是给遗留代码补测试，看着那一堆业务逻辑，根本不知道从哪里下手。测主干流程？边界条件？异常处理？感觉样样都要测，但又不知道优先级。

3. 写了也不知道对不对

测试代码也是代码，也会写错。我经常遇到测试通过了，但功能其实有问题；或者测试一直失败，但查了半天发现是测试写错了。

4. 正反馈太慢

写功能代码，跑起来看到效果，是有即时满足感的。但写测试？吭哧吭哧写半天，只是"确认代码没问题"，心理上没什么获得感。

这些痛点叠加起来，就形成了"我知道该写但就是不写"的怪圈。

---

/test 的核心能力

Claude Code的 /test skill，核心能力就一句话：根据你的代码自动生成测试用例草稿。

但它不是简单的"代码复制粘贴"，而是会做这几件事：

1. 分析代码逻辑分支

比如这个函数：

    
    
    
  def calculate_discount(price, user_type, coupon_code=None):
    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, encoding='utf-8', skip_errors=True):
    results = []
    with open(file_path, 'r', encoding=encoding) as f:
        reader = csv.DictReader(f)
        for row_num, row in enumerate(reader, start=2):
            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。