Python 测试

要解决什么问题

在 Python 项目里，测试往往卡在「该测什么、怎么拆用例、断言写在哪一层」——而不是缺一个 pytest 命令。模块边界不清时，单元测试容易变成对实现细节的锁死；集成测试又容易拖慢本地反馈。团队若缺少统一约定，还会出现 fixture 散落、mock 滥用、以及「只跑 happy path」的覆盖率假象。

本技能面向开发编程场景，帮助你在写业务代码的同时，把测试当成可维护的工程资产来组织，而不是事后补几行 assert。

技能如何协助你

在与大模型协作时，技能会把对话约束在 Python 测试相关的语境里，典型包括：

• 用例分层：区分纯函数/领域逻辑与 I/O、数据库、HTTP 等外部依赖，决定何时用 unittest.mock 或 pytest fixture 隔离。
• 结构与命名：按模块或行为组织 tests/，用可读的测试名表达「给定—当—则」，减少「test_1」类维护成本。
• 断言与数据：选用合适的断言方式（pytest.raises、参数化、subtests 等），避免脆弱的字面量比对。
• 回归与重构：在改实现时先明确「行为契约」再改测试，避免测试与实现同进退却测不到真实风险。

原始技能说明极为简短（Test），实际能力主要来自你在对话中提供的代码上下文与目标；技能的作用是聚焦问题域，而不是替代本地测试运行器。

适用边界与注意点

• 技能不会替你执行测试、生成 CI 配置或保证覆盖率达标；仍需在本地或流水线中运行 pytest / unittest 并解读失败栈。
• 对异步、多进程、GUI 等场景，需要你在提示中说明框架与约束，否则建议可能过于通用。
• 安全敏感或合规场景下，测试数据与密钥管理须按你们团队规范处理，不要依赖模型「猜」环境变量。

若项目已有测试规范文档，把关键片段贴进对话，效果通常比泛泛问「怎么写测试」更好。