测试设计与运行

让 Copilot 写测试之前，提供被测代码、已有测试样例、框架和运行方式。生成结果的价值取决于断言是否表达需求，以及测试是否能在项目环境中运行。

单元测试先列行为再写代码

可以选择目标函数并使用 /tests，要求覆盖成功、失败与边界；也可以在提示里引用既有测试文件，沿用其风格。官方示例使用 #file: path/to/test-file.js 指向参考文件，实际路径应替换为项目中的文件。

对于“价格必须大于零且不超过上限”一类规则，应分别检查正常值、零、负数、上限和超过上限的输入。边界条件应由业务规则确定，不能只复制教程中的价格数值。

如果项目还没有配置测试框架，Copilot 可能先提供配置步骤；这不等于配置已经执行。先确认现有工具链，再检查生成文件能否被测试运行器发现，以及失败断言是否确实会失败。

用 mock 隔离依赖

官方 SvelteKit 示例将服务调用 mock 掉，使页面加载函数的测试不依赖真实数据库。Vitest 示例使用 vi.mock 和 vi.fn，为服务设置返回值，并在测试之间清理 mock 状态。

这类测试应同时关注三个方面：

1. 调用依赖时传入的参数是否正确。
2. 调用次数是否符合被测行为。
3. 返回给调用方的结果是否符合预期结构。

只设置一个返回值而不检查调用关系，可能让错误参数继续通过测试。反过来，mock 测试通过也不能证明真实服务、数据库或网络已经连通；需要根据目标增加相应的集成验证。

端到端测试覆盖页面状态

官方网页教程以 React 商品详情为例，展示 Playwright 测试；也可以根据项目要求让 Copilot 使用已有的其他框架。提供实际页面路由、接口路径和现有测试文件，避免让模型猜测地址或选择器。

教程覆盖加载中、成功显示详情和请求失败后的错误状态，并通过路由响应控制成功与失败场景。验收时检查测试是否等待正确的页面状态，是否断言了用户真正可见的内容，而不是仅确认某次网络请求发生。

如果测试需要观察加载中状态，应让响应时机可控，避免响应立即完成使断言偶发错过该状态。网络替身适合验证页面对指定响应的处理，但不能代替对真实后端的集成测试。

运行后再决定是否采用

检查生成代码是否使用项目安装的框架 API，是否需要真实浏览器或启动服务，以及清理过程是否会影响后续用例。运行相关测试，阅读失败输出，再让 Copilot针对具体问题修正。

不要把“生成了很多测试”视为覆盖充分。优先保留能够捕获真实回归、符合项目行为且运行稳定的场景，再根据风险补足遗漏。