AI效率陷阱:我为何开发工具指导Cursor进行测试

我爱免费

作者：微信文章
我一直是个务实的测试者。

如果测试覆盖率达不到100%，我并不会因此失眠。我优先测试关键路径，关注那些处理金钱、数据完整性和复杂逻辑的代码。我从来不会为了在代码仓库里看到一个绿色徽章，就浪费时间为getter/setter方法或样板式的 str 表示法编写单元测试。

但随后，AI革命来了。

和许多人一样，我开始使用 Cursor 这类工具来加速工作流程。突然间，编写测试的成本降到了接近零。我变得贪婪起来，开始发出“提高测试覆盖率”和“让我们达到85%”这样的指令。

AI欣然应允，以我无法企及的速度大量生成测试。我看着覆盖率百分比不断攀升，感觉很有成效。

然而，当我审视生成的代码时，问题出现了。

AI在钻系统的空子。它本能地选择了阻力最小的路径，为那些唾手可得的工具函数、配置解析器和琐碎代码编写了数百个测试，因为这些很容易验证。

与此同时，那些复杂的、高风险的业务逻辑——那些真正会导致生产环境崩溃的部分——却被跳过了。AI使用的启发式方法似乎认为，与容易得手的成果相比，这些逻辑“太难”或“优先级太低”。

我发现自己花了数小时监督AI，等待漫长的实现和重构周期，结果却发现应用程序的结构完整性并未得到实质性改善。我只是淹没在“绿色构建”这种虚荣指标里。

我需要一种方法来迫使AI像高级工程师一样思考。我需要一个评分系统，能够明确指出：“忽略那些简单的东西，专注于高影响、低复杂性的部分。”

这就是我构建 pytest-coverage-impact 的原因。
核心理念：投资回报率高于虚荣指标


pytest-coverage-impact 是一个为测试套件引入投资回报率（ROI）逻辑的插件。它解析代码的抽象语法树（AST），构建调用图，并使用机器学习根据两个因素为代码库中的每个函数打分：

影响（爆炸半径）： 有多少其他函数依赖于此？如果 process_payment() 出问题，应用就崩溃了；如果 get_pretty_name() 出问题，只是日志看起来难看。复杂性（阻力）： 为此编写测试有多难？

该插件使用以下公式生成 优先级分数：

这是对RICE评分模型的修改版，强调将复杂性和工作量作为优先级排序的分母。

这个分数为我（和我的AI助手）提供了一个优先处理清单。我不再要求Cursor“提高覆盖率”，而是可以粘贴影响报告中的前5个函数，然后指示：“为这些特定函数编写测试。”
技术内幕：用于代码的机器学习


大多数工具仅通过计算嵌套的if语句（圈复杂度）来衡量“复杂性”。我希望能更智能一些。

我训练了一个随机森林模型来预测 “测试痛点”。该模型通过分析静态代码特征，来推测测试一个函数会有多麻烦：

副作用： 它是否触及文件系统、网络或外部API（如Snowflake）？测试结构： 测试这个函数通常是否需要模拟对象、夹具或集成标记？

该工具预测测试工作的复杂程度，范围从0.0到1.0。

高优先级： 高影响 + 低复杂性（“必须拥有”）低优先级： 低影响 + 高复杂性（“时间黑洞”）

它甚至计算随机森林中各棵树之间的 方差。如果模型对其预测不自信（置信区间宽），它会自动降低该函数的优先级。我们只想追求确定的事情。
杀手级功能：用你的代码训练它


每个代码库都不同。在单体Web应用中算作“复杂”的东西，与在数据工程仓库中的定义可能完全不同。

我将一个训练管道直接集成到了CLI中，这样工具就可以从 _你_ 现有的测试中学习。
如何使用


我设计这个工具是为了直接融入现有的工作流程。

安装：
pip install pytest-coverage-impact

运行分析：
pytest --cov=my_project --coverage-impact

输出结果： 你得到的不是一个文本墙，而是一个优先级的待办事项列表：
按优先级排序的顶级函数（影响 / 复杂性）
┏━━━━━━━━━━┳━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃ 优先级 ┃ 分数 ┃ 影响 ┃ 复杂性    ┃ 函数         ┃
┡━━━━━━━━━━╇━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│        1 │  2.45 │   12.5 │  0.65 [±0.15] │ auth.py::login   │
│        2 │  1.80 │    8.0 │  0.20 [±0.05] │ utils.py::parser │

在这个例子中，auth.py::login 是胜出者。它具有高影响，并且模型确信它是可测试的。这使我能够精确地告诉Cursor它需要关注哪里。
起源故事


我最初并没有打算构建一个独立的pytest插件。

当时我正在对 Snowfort（我的Snowflake管理工具——请密切关注即将发布的新版本，这是一个巨大的升级）进行完全重写。

我盯着空白的代码，意识到在构建新功能时，我需要一种方法来保持测试的专注。我创建了这些脚本来帮助我在Snowfort重写中进行优先级排序，然后意识到这个逻辑可以帮助任何厌倦了AI编写无用测试的Python开发者。
总结


在AI时代，代码生成很廉价，但 策略却很昂贵。

pytest-coverage-impact 充当了你AI编码助手的瞄准系统。它阻止AI用低价值的测试来填充统计数据，并迫使它去解决应用程序的结构完整性问题。

GitHub仓库： https://github.com/noah-goodrich/pytest-coverage-impactPyPI： pip install pytest-coverage-impact

如果你用这个工具在你的代码中发现了任何“隐藏的巨龙”，请告诉我。