ChatGPT写单元测试提示词怎么加示例：结果更稳定

必须加示例，因为模型需锚定输入格式、断言风格、结构粒度三维度；示例须真实、可运行、无注释，并完整包含参数调用、字面量预期结果及fixture名称。

你想让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。