flutter-testing

Flutter 测试

在能够提供信心的前提下，选择成本最低的层级来测试可观察行为。

选择测试层级

• 单元测试：纯逻辑、状态转换、仓库、解析和故障处理策略。
• Widget 测试：渲染、语义、交互、焦点、导航连接，以及状态到 UI 的行为。
• Golden 测试：当平台和字体控制能让比较有意义时，验证稳定的视觉契约。
• 集成测试：关键流程、插件集成、性能，以及需要真实目标环境的行为。

不要用实现细节（例如调用私有方法或精确匹配 Widget 树结构）代替行为断言。

可靠性

• 需要确定性时，注入时钟、随机性、存储和传输层。
• 优先使用小型伪实现，而不是庞大的模拟对象图；验证输出和副作用，而非偶然发生的调用。
• 使用测试框架控制异步进度；避免任意等待。
• 持续触发帧，直到达到已知状态或有界完成；当动画或计时器持续运行时，避免无界调用 pumpAndSettle。
• 为测试提供彼此独立的数据，并清理全局绑定、文件、数据库和订阅。
• 只有在检查渲染差异后，才更新 golden。

可丢弃的测试探针

创建新测试前，先将其分类。将回归测试、验收测试和规范测试作为项目的常规文件保留。测试通过并不是删除它的理由。

对于不应提交的一次性诊断探针：

• 如果运行器允许，优先在仓库外的独立临时项目或目录中进行。
• 如果探针必须放在 test/ 或 integration_test/ 下，选择一个明确且唯一的路径，记录创建前该路径是否已存在或受版本控制，并拒绝覆盖；同时将文件标记为生成文件且可丢弃。
• 创建路径后立即注册主机端清理，以便成功或失败后都能执行。在清理前保留测试退出状态和有用输出。
• 只删除当前运行创建的产物。绝不要递归删除测试目录、使用宽泛的 glob，或将删除预存或受版本控制的测试作为常规清理操作。
• 在报告完成或准备提交之前，确认记录的路径已不存在，并将限定范围的 git status 与运行前状态进行比较。如果执行被中断，应再次检查，而不是假定清理已执行。

对于测试内部创建的运行时文件、数据库、绑定和订阅，使用 addTearDown 等测试框架的 teardown。它不能替代主机端对临时 Dart 源文件的清理。如果探针发现了可复现的缺陷，除非用户明确只需要临时证据，否则优先将其转化为持久的回归测试。

在选择边界、伪实现、插件接缝或原生 UI 覆盖范围时，加载 测试层级与替身。遇到异步不稳定、视觉契约、设备流程或可丢弃测试产物时，加载 确定性、golden、集成与清理。

验证

有条件时，使用 Dart 和 Flutter MCP 测试能力；否则使用仓库既定的测试命令。迭代期间先运行范围较小的测试，然后再运行相关测试套件。分别报告执行环境和数据来源，例如：使用 fixture 的 Widget 测试，或调用 staging 的 iOS 模拟器测试。应说明跳过的平台、不稳定行为或环境依赖，而不是将其视为成功。

来源

• Flutter 测试
• 集成测试
• Dart 和 Flutter MCP 服务