ChatGPT单元测试提示词示例：结果更稳定的技巧

先说一个核心判断：想让ChatGPT生成能直接运行的单元测试代码，不加示例是行不通的。

你是不是也遇到过这种情况？每次让模型写测试，输出的断言方式、测试函数命名、fixture用法都不一致，有时候连import语句都漏掉，甚至直接给你一段伪代码——根本没法贴进项目里跑。这真不是模型能力的问题，关键在于提示词没给它一个“可以对齐的标尺”。加示例不是锦上添花，而是把模糊意图转化成可验证动作的关键一步。

为什么必须加示例

模型没见过你项目里的函数签名、异常类型、测试框架版本，更不知道你团队约定的assert写法——是用self.assertEqual还是expect(...)？不给示例，它只能按通用模板猜，而猜出来的结果常常在Pytest、unittest、Jest之间来回漂移。

示例的作用，说白了就是锚定三个维度：输入格式、断言风格、结构粒度。这三者缺一不可。

加示例的三步实操法

第一步：从你当前的代码库里找一个真实存在、逻辑清晰的函数作为示例对象。必须是你能跑通的函数，不能虚构。模型一旦发现你在编造函数，它就会跟着模仿虚构逻辑，完全偏离你真实的约束条件。

第二步：亲手写一段你认可的、可直接运行的测试代码——哪怕只有1个测试用例也行。关键是要保留：函数调用方式、参数传入形式（是字面量、变量还是fixture）、断言语句的完整结构（包括错误消息字符串），以及是否包含setup/teardown逻辑。

第三步：把这段真实的测试代码原样嵌入提示词里，放在“请生成测试”指令后面，用明确的分隔符标出来。比如这样：

请为以下函数生成3个覆盖不同分支的Pytest测试用例：
def calculate_discount(price: float, category: str) -> float:
    ...

以下是我期望的测试风格示例：
```python
def test_calculate_discount_normal_case():
    assert calculate_discount(100.0, "electronics") == 90.0
```

两种高效示例嵌入方式

方法一：单例强约束型（适合新手或统一规范场景）
只提供1个最简但要素齐全的测试函数。要求模型严格复现命名规则（test_前缀）、断言语法（==而非is），并且不能有多余的print语句。这种写法会让输出高度收敛，但灵活性会稍差一些。

方法二：多例对比型（适合复杂函数或混合框架）
并列给出2个示例：一个正常路径，一个异常路径。例如：

```python
def test_parse_json_valid_input():
    assert parse_json('{"key": "value"}') == {"key": "value"}

def test_parse_json_invalid_input():
    with pytest.raises(JSONDecodeError):
        parse_json('{invalid}')
```

这相当于在告诉模型：“你要覆盖happy path和error path，而且error path必须用with pytest.raises”。

注意：两个示例必须来自同一个函数、同一个测试文件，否则模型容易混淆上下文。

示例里必须包含的3个硬性要素

① 函数调用的完整参数列表——不能省略默认参数值，否则模型可能生成缺失参数的调用。
② 断言右侧的预期结果必须是字面量（比如42、"ok"、[1,2,3]），不能写成变量名或表达式，否则模型会直接复制变量名，运行时报NameError。
③ 如果用了fixture（比如client、db_session），示例里必须出现fixture名称，并且要和pytest配置保持一致，否则生成的测试没法setup。

这三条里任何一条缺失，都可能导致生成的测试代码在CI流水线第一轮就跑失败。

避坑：别把示例写成“教学模板”

一个常见的错误是：在示例里写注释解释“这里用assert是因为……”，或者加一行“# 注意：每个测试只测一个关注点”。模型会把注释也当作代码结构的一部分，最终生成带着同样注释的测试代码，反而污染了可执行代码。

正确的做法：示例就是干净、可运行、无注释的代码块。所有解释性内容，全部放在“请生成……”的指令句里。

现在，把你的目标函数和一段真实测试代码组合进提示词，直接发给ChatGPT就行。