ECC Dart/Flutter 测试规范实战指南从单元测试到黄金测试的完整落地手册【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本指南以 ECC 仓库的 Dart/Flutter 测试规则英文版位于 rules/dart/testing.md为核心骨架结合 common 层测试规范、Flutter 测试命令 与 Flutter/Dart 代码评审技能 等仓库源码证据系统讲解 Dart/Flutter 项目在 ECC 规则体系下的测试工程化实践。读完本文你将掌握测试框架与工具链的选型、四类测试的编写范式单元/Widget/黄金/集成、状态管理器测试的标准写法、Fake 优先于 Mock 的设计原则、异步与时间控制技巧以及一套可直接复制的目录结构与覆盖率门槛。一、测试框架与工具链选型ECC 的 Dart/Flutter 规则rules/dart/testing.md明确规定了测试框架与配套工具它们是编写各类测试的基础设施工具用途flutter_test/dart:test内置测试运行器是所有测试的公共底座mockito配合GenerateMocks或mocktail无需代码生成依赖桩替身bloc_testBLoC/Cubit 状态管理器的单元测试fake_async在单元测试中精确控制时间Timer、Future 调度integration_test真机/模拟器上的端到端设备测试从仓库配套的 Flutter 测试命令 可以看到flutter test是整个测试体系的执行入口同时支持--coverage覆盖率收集、--name按名称模式筛选、--update-goldens更新黄金文件、按文件路径定点运行等能力与规则文件中的工具链一一对应。二、测试类型全景四种测试的分工与书写时机规则文件给出了完整的测试类型矩阵这是团队统一测试语言的基础类型工具目录书写时机单元测试dart:testtest/unit/所有领域逻辑、状态管理器、仓储RepositoryWidget 测试flutter_testtest/widget/所有具有有意义行为的 Widget黄金测试flutter_testtest/golden/设计关键的 UI 组件集成测试integration_testintegration_test/真机/模拟器上的关键用户流程这一矩阵与 common 层测试规范 中单元测试、集成测试、E2E 测试全部必需的要求一脉相承语言特定规则在其基础上细化出 Widget 与黄金测试两个 Flutter 特有类别。三、单元测试状态管理器的标准写法状态管理器是 Flutter 业务逻辑的核心载体规则文件给出了两大主流方案BLoC 与 Riverpod的测试范式这两份代码可以直接复制到项目中作为模板。3.1 使用bloc_test测试 BLoCBLoC 采用事件驱动模型测试核心是验证给定事件 → 期望状态流。规则文件中的完整示例group(CartBloc, () { late CartBloc bloc; late MockCartRepository repository; setUp(() { repository MockCartRepository(); bloc CartBloc(repository); }); tearDown(() bloc.close()); blocTestCartBloc, CartState( CartItemAdded 時に更新されたアイテムを emit する, build: () bloc, act: (b) b.add(CartItemAdded(testItem)), expect: () [CartState(items: [testItem])], ); blocTestCartBloc, CartState( CartCleared 時に空のカートを emit する, seed: () CartState(items: [testItem]), build: () bloc, act: (b) b.add(CartCleared()), expect: () [const CartState()], ); });关键要点拆解blocTestTBloc, TState泛型同时约束 Bloc 与 State 类型build负责构造被测实例act注入事件expect声明期望的完整状态序列seed用于构造非初始状态的测试起点如购物车已有商品时清空避免重复构造前置状态setUp/tearDown依赖在setUp中装配Bloc 在tearDown中close()保证测试隔离不泄漏资源。仓库中的 BLoC 模式参考 展示了对应的CartBloc/CartEvent/CartState实现其中事件用sealed class建模、状态用不可变类加copyWith——这套模式让blocTest的expect断言天然精确且不可能出现非法状态组合。3.2 使用ProviderContainer测试 RiverpodRiverpod 的测试思路与 BLoC 截然不同不依赖 Widget 树直接构建独立的ProviderContainer通过overrides注入替身依赖test(usersProvider がリポジトリからユーザーをロードする, () async { final container ProviderContainer( overrides: [userRepositoryProvider.overrideWithValue(FakeUserRepository())], ); addTearDown(container.dispose); final result await container.read(usersProvider.future); expect(result, isNotEmpty); });要点ProviderContainer是 Riverpod 在纯 Dart 环境下的测试入口无需ProviderScopeWidgetoverrideWithValue将仓库 provider 替换为FakeUserRepository注意这里是Fake呼应下文Fake 优先原则addTearDown(container.dispose)确保容器在测试结束后释放避免 provider 状态在用例间串扰。四、Widget 测试验证界面行为Widget 测试通过testWidgets与tester在模拟环境中渲染并交互 Widget规则文件给出的是注入替身状态 → 渲染页面 → 断言 UI 表现的范式testWidgets(CartPage がアイテム数バッジを表示する, (tester) async { await tester.pumpWidget( ProviderScope( overrides: [ cartNotifierProvider.overrideWith(() FakeCartNotifier([testItem])), ], child: const MaterialApp(home: CartPage()), ), ); await tester.pump(); expect(find.text(1), findsOneWidget); expect(find.byType(CartItemTile), findsOneWidget); }); testWidgets(カートが空のときに空の状態を表示する, (tester) async { await tester.pumpWidget( ProviderScope( overrides: [cartNotifierProvider.overrideWith(() FakeCartNotifier([]))], child: const MaterialApp(home: CartPage()), ), ); await tester.pump(); expect(find.text(Your cart is empty), findsOneWidget); });实操要点pumpWidget渲染被测页面注意用ProviderScope或BlocProvider包裹并包一层MaterialApp以提供主题与导航环境pump()推进一帧让异步构建/首次状态更新落地后再断言对于含动画或持续异步的场景规则见 Flutter/Dart 代码评审技能 的测试章节进一步要求使用pumpAndSettle()或显式pump(Duration)而不是依赖时间假设以避免 flaky 测试Finder 断言find.text匹配文案、find.byType匹配 Widget 类型配合findsOneWidget/findsNothing等匹配器。五、Fake 优先于 Mock规则文件明确提出复杂依赖优先使用手写 Fakeモックよりもフェイクを優先。Fake 是接口的真实实现但以内存数据代替真实 IO可控性远高于行为交互型 Mock。完整示例class FakeUserRepository implements UserRepository { final _users String, User{}; Object? fetchError; override FutureUser? getById(String id) async { if (fetchError ! null) throw fetchError!; return _users[id]; } override FutureListUser getAll() async { if (fetchError ! null) throw fetchError!; return _users.values.toList(); } override StreamListUser watchAll() Stream.value(_users.values.toList()); override Futurevoid save(User user) async { _users[user.id] user; } override Futurevoid delete(String id) async { _users.remove(id); } void addUser(User user) _users[user.id] user; }这个 Fake 的设计亮点内存 Map 模拟数据源getAll/getById/save/delete都是对_users的增删查行为真实可信错误注入钩子fetchError字段让测试可以随时让下一次调用抛异常从而覆盖加载失败路径——这是 Fake 优于硬编码 Stub 的核心价值测试辅助方法addUser直接在内存中预置数据省去save调用链。这一原则同样体现在 common 层测试规范 中验证 mock 是否正确、保证测试隔离的排障条目以及 Flutter 测试命令 中MissingPluginException → 在测试 setup 中 Mock 平台通道的典型失败修复指引。六、异步测试与时间控制fake_async依赖真实时钟的测试防抖、轮询、超时既慢又不可控规则文件给出的方案是用fake_async手动拨动时间// タイマーと Future を制御するために fake_async を使用 test(300ms 後にデバウンスが発火する, () { fakeAsync((async) { final debouncer Debouncer(delay: const Duration(milliseconds: 300)); var callCount 0; debouncer.run(() callCount); expect(callCount, 0); async.elapse(const Duration(milliseconds: 200)); expect(callCount, 0); async.elapse(const Duration(milliseconds: 200)); expect(callCount, 1); }); });要点fakeAsync包裹的代码块中Timer 与 Future 都由虚拟时钟调度测试瞬时完成async.elapse(duration)一次性推进虚拟时钟同步触发所有到期回调断言穿插在时间推进之间精确验证200ms 未触发、累计 400ms 后恰好触发一次的防抖语义。这与 Flutter 测试命令 中pumpAndSettle timed out → 替换为显式 pump(Duration)的排障建议形成互补Widget 侧用 pump 控制帧推进纯 Dart 侧用 fake_async 控制时钟。七、黄金测试设计关键组件的像素级回归黄金测试将 Widget 渲染结果与基线图片逐像素比对用于守护设计关键组件不被无意改动破坏testWidgets(UserCard ゴールデンテスト, (tester) async { await tester.pumpWidget( MaterialApp(home: UserCard(user: testUser)), ); await expectLater( find.byType(UserCard), matchesGoldenFile(goldens/user_card.png), ); });工作流要点matchesGoldenFile将find.byType(UserCard)捕获的渲染结果与goldens/下的基准图比对有意的视觉变更执行flutter test --update-goldens重新生成基准图该命令在 Flutter 测试命令 中同样被列为标准操作无意的视觉变更测试失败即阻断合并配合 diff 工具定位差异。八、测试命名规范规则文件要求使用描述性、以行为为中心的命名让测试失败信息本身就能说明问题test(ユーザーが存在しない場合に null を返す, () { ... }); test(id が空文字列の場合に NotFoundException をスローする, () { ... }); testWidgets(フォームが無効な間は送信ボタンを無効にする, (tester) async { ... });命名模式提炼为行为做什么 条件什么情况下→ 结果期望什么。这与 common 层测试规范 中的 AAAArrange-Act-Assert结构与行为式命名要求一致后者给出的示例如returns empty array when no markets match query、throws error when API key is missing是同一套哲学的 TypeScript 表达。九、测试目录结构规范规则文件给出了明确的目录约定测试与源码分层一一对应test/ ├── unit/ │ ├── domain/ │ │ └── usecases/ │ └── data/ │ └── repositories/ ├── widget/ │ └── presentation/ │ └── pages/ └── golden/ └── widgets/ integration_test/ └── flows/ ├── login_flow_test.dart └── checkout_flow_test.dart这一结构与 patterns 规则 中的 Clean Architecture 分层domain纯 Dart /data仓储实现 /presentationWidget 与状态管理严格对齐unit/domain、unit/data分别测试用例与仓储widget/presentation测试页面golden/widgets测试视觉组件integration_test/flows承载端到端用户流程。仓库中的 Flutter 测试命令 给出了对应的定点运行方式例如flutter test test/unit/domain/usecases/get_user_test.dart。十、覆盖率门槛与 CI 阻断规则文件对覆盖率提出硬性要求业务逻辑领域层 状态管理器行覆盖率 ≥ 80%所有状态迁移必须有测试加载中 → 成功、加载中 → 错误、重试等路径全覆盖执行flutter test --coverage通过覆盖率报告器查看lcov.info覆盖率低于阈值时 CI 必须阻断。仓库中的证据相互印证common 层测试规范 同样将最低覆盖率 80%列为通用强制要求并规定 TDD 工作流先写测试 RED → 运行确认失败 → 最小实现 GREEN → 重构 IMPROVE → 验证覆盖率 80%Flutter 测试命令 的示例会话展示了覆盖率基线如 84.2%目标 80%如何作为测试运行报告的最终验收指标状态迁移全覆盖这一点在 Flutter/Dart 代码评审技能 的测试检查清单中被列为硬性条目所有状态迁移都有对应测试loading → success, loading → error, retry, empty。十一、落地实操把规范接进日常工具链测试规范不是孤立文档ECC 仓库为它配套了一整条工具链让规则可以被执行11.1 提交前检查来自 hooks 规则dart format --set-exit-if-changed . dart analyze --fatal-infos flutter test11.2 日常常用命令# 全部测试 flutter test 21 # 带覆盖率 flutter test --coverage 21 # 运行单个测试文件 flutter test test/unit/domain/usecases/get_user_test.dart 21 # 按名称模式筛选如所有 CartBloc 测试 flutter test --name CartBloc 21 # 集成测试需要真机/模拟器 flutter test integration_test/ 21 # 有意的视觉变更后更新黄金文件 flutter test --update-goldens 2111.3 自动化的编辑后格式化可选在~/.claude/settings.json中配置 PostToolUse Hook编辑.dart文件后自动执行dart format{ hooks: { PostToolUse: [ { matcher: { tool_name: Edit, file_paths: [**/*.dart] }, hooks: [ { type: command, command: dart format $CLAUDE_FILE_PATHS } ] } ] } }11.4 Agent 与技能支持排障与 TDD 兜底当测试失败时common 层测试规范 要求主动调用tdd-guideAgent 排查先检查测试隔离与 Mock 正确性再决定是修实现还是修测试自动化测试执行/flutter-test命令commands/flutter-test.md可以运行测试套件、按类型解析失败原因、逐个增量修复并复跑验证评审兜底合并前由 flutter-reviewer Agent 按评审清单核查状态管理器变更是否有对应单元测试、新 Widget 是否有 Widget 测试、设计关键组件是否有黄金测试、状态迁移是否全覆盖等条目并与 flutter-dart-code-review 技能中的完整测试检查清单配合使用。十二、常见失败模式速查结合 Flutter 测试命令 中沉淀的典型失败与修复路径整理如下失败现象典型修复Expected: X Actual: Y修正断言或修复实现Widget not found修正 Finder 选择器Widget 改名后同步更新测试Golden file not found运行flutter test --update-goldens生成基准图Golden mismatch检查差异若为有意变更则--update-goldensMissingPluginException在测试 setup 中 Mock 平台通道LateInitializationError在setUp()中初始化late字段pumpAndSettle timed out替换为显式pump(Duration)调用结语ECC 的 Dart/Flutter 测试规则英文原版、日文版与 common 层规范、patterns 规则、Flutter 测试命令 共同构成了一套规范定义 → 目录约束 → 命令执行 → Agent 评审的闭环测试工程体系。实践落地的要点可以浓缩为五句话单元测试覆盖全部业务逻辑与状态管理器Fake 优先于 Mock复杂依赖一律手写可控替身Widget 与黄金测试守护界面行为与像素级设计状态迁移加载/成功/错误/重试必须全部有测试业务逻辑行覆盖率不低于 80% 且由 CI 强制阻断。照着这套规范执行你的 Dart/Flutter 项目将同时获得可维护性、可回归性与可审查性三重保障。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC Dart/Flutter 测试规范实战指南：从单元测试到黄金测试的完整落地手册
ECC Dart/Flutter 测试规范实战指南从单元测试到黄金测试的完整落地手册【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本指南以 ECC 仓库的 Dart/Flutter 测试规则英文版位于 rules/dart/testing.md为核心骨架结合 common 层测试规范、Flutter 测试命令 与 Flutter/Dart 代码评审技能 等仓库源码证据系统讲解 Dart/Flutter 项目在 ECC 规则体系下的测试工程化实践。读完本文你将掌握测试框架与工具链的选型、四类测试的编写范式单元/Widget/黄金/集成、状态管理器测试的标准写法、Fake 优先于 Mock 的设计原则、异步与时间控制技巧以及一套可直接复制的目录结构与覆盖率门槛。一、测试框架与工具链选型ECC 的 Dart/Flutter 规则rules/dart/testing.md明确规定了测试框架与配套工具它们是编写各类测试的基础设施工具用途flutter_test/dart:test内置测试运行器是所有测试的公共底座mockito配合GenerateMocks或mocktail无需代码生成依赖桩替身bloc_testBLoC/Cubit 状态管理器的单元测试fake_async在单元测试中精确控制时间Timer、Future 调度integration_test真机/模拟器上的端到端设备测试从仓库配套的 Flutter 测试命令 可以看到flutter test是整个测试体系的执行入口同时支持--coverage覆盖率收集、--name按名称模式筛选、--update-goldens更新黄金文件、按文件路径定点运行等能力与规则文件中的工具链一一对应。二、测试类型全景四种测试的分工与书写时机规则文件给出了完整的测试类型矩阵这是团队统一测试语言的基础类型工具目录书写时机单元测试dart:testtest/unit/所有领域逻辑、状态管理器、仓储RepositoryWidget 测试flutter_testtest/widget/所有具有有意义行为的 Widget黄金测试flutter_testtest/golden/设计关键的 UI 组件集成测试integration_testintegration_test/真机/模拟器上的关键用户流程这一矩阵与 common 层测试规范 中单元测试、集成测试、E2E 测试全部必需的要求一脉相承语言特定规则在其基础上细化出 Widget 与黄金测试两个 Flutter 特有类别。三、单元测试状态管理器的标准写法状态管理器是 Flutter 业务逻辑的核心载体规则文件给出了两大主流方案BLoC 与 Riverpod的测试范式这两份代码可以直接复制到项目中作为模板。3.1 使用bloc_test测试 BLoCBLoC 采用事件驱动模型测试核心是验证给定事件 → 期望状态流。规则文件中的完整示例group(CartBloc, () { late CartBloc bloc; late MockCartRepository repository; setUp(() { repository MockCartRepository(); bloc CartBloc(repository); }); tearDown(() bloc.close()); blocTestCartBloc, CartState( CartItemAdded 時に更新されたアイテムを emit する, build: () bloc, act: (b) b.add(CartItemAdded(testItem)), expect: () [CartState(items: [testItem])], ); blocTestCartBloc, CartState( CartCleared 時に空のカートを emit する, seed: () CartState(items: [testItem]), build: () bloc, act: (b) b.add(CartCleared()), expect: () [const CartState()], ); });关键要点拆解blocTestTBloc, TState泛型同时约束 Bloc 与 State 类型build负责构造被测实例act注入事件expect声明期望的完整状态序列seed用于构造非初始状态的测试起点如购物车已有商品时清空避免重复构造前置状态setUp/tearDown依赖在setUp中装配Bloc 在tearDown中close()保证测试隔离不泄漏资源。仓库中的 BLoC 模式参考 展示了对应的CartBloc/CartEvent/CartState实现其中事件用sealed class建模、状态用不可变类加copyWith——这套模式让blocTest的expect断言天然精确且不可能出现非法状态组合。3.2 使用ProviderContainer测试 RiverpodRiverpod 的测试思路与 BLoC 截然不同不依赖 Widget 树直接构建独立的ProviderContainer通过overrides注入替身依赖test(usersProvider がリポジトリからユーザーをロードする, () async { final container ProviderContainer( overrides: [userRepositoryProvider.overrideWithValue(FakeUserRepository())], ); addTearDown(container.dispose); final result await container.read(usersProvider.future); expect(result, isNotEmpty); });要点ProviderContainer是 Riverpod 在纯 Dart 环境下的测试入口无需ProviderScopeWidgetoverrideWithValue将仓库 provider 替换为FakeUserRepository注意这里是Fake呼应下文Fake 优先原则addTearDown(container.dispose)确保容器在测试结束后释放避免 provider 状态在用例间串扰。四、Widget 测试验证界面行为Widget 测试通过testWidgets与tester在模拟环境中渲染并交互 Widget规则文件给出的是注入替身状态 → 渲染页面 → 断言 UI 表现的范式testWidgets(CartPage がアイテム数バッジを表示する, (tester) async { await tester.pumpWidget( ProviderScope( overrides: [ cartNotifierProvider.overrideWith(() FakeCartNotifier([testItem])), ], child: const MaterialApp(home: CartPage()), ), ); await tester.pump(); expect(find.text(1), findsOneWidget); expect(find.byType(CartItemTile), findsOneWidget); }); testWidgets(カートが空のときに空の状態を表示する, (tester) async { await tester.pumpWidget( ProviderScope( overrides: [cartNotifierProvider.overrideWith(() FakeCartNotifier([]))], child: const MaterialApp(home: CartPage()), ), ); await tester.pump(); expect(find.text(Your cart is empty), findsOneWidget); });实操要点pumpWidget渲染被测页面注意用ProviderScope或BlocProvider包裹并包一层MaterialApp以提供主题与导航环境pump()推进一帧让异步构建/首次状态更新落地后再断言对于含动画或持续异步的场景规则见 Flutter/Dart 代码评审技能 的测试章节进一步要求使用pumpAndSettle()或显式pump(Duration)而不是依赖时间假设以避免 flaky 测试Finder 断言find.text匹配文案、find.byType匹配 Widget 类型配合findsOneWidget/findsNothing等匹配器。五、Fake 优先于 Mock规则文件明确提出复杂依赖优先使用手写 Fakeモックよりもフェイクを優先。Fake 是接口的真实实现但以内存数据代替真实 IO可控性远高于行为交互型 Mock。完整示例class FakeUserRepository implements UserRepository { final _users String, User{}; Object? fetchError; override FutureUser? getById(String id) async { if (fetchError ! null) throw fetchError!; return _users[id]; } override FutureListUser getAll() async { if (fetchError ! null) throw fetchError!; return _users.values.toList(); } override StreamListUser watchAll() Stream.value(_users.values.toList()); override Futurevoid save(User user) async { _users[user.id] user; } override Futurevoid delete(String id) async { _users.remove(id); } void addUser(User user) _users[user.id] user; }这个 Fake 的设计亮点内存 Map 模拟数据源getAll/getById/save/delete都是对_users的增删查行为真实可信错误注入钩子fetchError字段让测试可以随时让下一次调用抛异常从而覆盖加载失败路径——这是 Fake 优于硬编码 Stub 的核心价值测试辅助方法addUser直接在内存中预置数据省去save调用链。这一原则同样体现在 common 层测试规范 中验证 mock 是否正确、保证测试隔离的排障条目以及 Flutter 测试命令 中MissingPluginException → 在测试 setup 中 Mock 平台通道的典型失败修复指引。六、异步测试与时间控制fake_async依赖真实时钟的测试防抖、轮询、超时既慢又不可控规则文件给出的方案是用fake_async手动拨动时间// タイマーと Future を制御するために fake_async を使用 test(300ms 後にデバウンスが発火する, () { fakeAsync((async) { final debouncer Debouncer(delay: const Duration(milliseconds: 300)); var callCount 0; debouncer.run(() callCount); expect(callCount, 0); async.elapse(const Duration(milliseconds: 200)); expect(callCount, 0); async.elapse(const Duration(milliseconds: 200)); expect(callCount, 1); }); });要点fakeAsync包裹的代码块中Timer 与 Future 都由虚拟时钟调度测试瞬时完成async.elapse(duration)一次性推进虚拟时钟同步触发所有到期回调断言穿插在时间推进之间精确验证200ms 未触发、累计 400ms 后恰好触发一次的防抖语义。这与 Flutter 测试命令 中pumpAndSettle timed out → 替换为显式 pump(Duration)的排障建议形成互补Widget 侧用 pump 控制帧推进纯 Dart 侧用 fake_async 控制时钟。七、黄金测试设计关键组件的像素级回归黄金测试将 Widget 渲染结果与基线图片逐像素比对用于守护设计关键组件不被无意改动破坏testWidgets(UserCard ゴールデンテスト, (tester) async { await tester.pumpWidget( MaterialApp(home: UserCard(user: testUser)), ); await expectLater( find.byType(UserCard), matchesGoldenFile(goldens/user_card.png), ); });工作流要点matchesGoldenFile将find.byType(UserCard)捕获的渲染结果与goldens/下的基准图比对有意的视觉变更执行flutter test --update-goldens重新生成基准图该命令在 Flutter 测试命令 中同样被列为标准操作无意的视觉变更测试失败即阻断合并配合 diff 工具定位差异。八、测试命名规范规则文件要求使用描述性、以行为为中心的命名让测试失败信息本身就能说明问题test(ユーザーが存在しない場合に null を返す, () { ... }); test(id が空文字列の場合に NotFoundException をスローする, () { ... }); testWidgets(フォームが無効な間は送信ボタンを無効にする, (tester) async { ... });命名模式提炼为行为做什么 条件什么情况下→ 结果期望什么。这与 common 层测试规范 中的 AAAArrange-Act-Assert结构与行为式命名要求一致后者给出的示例如returns empty array when no markets match query、throws error when API key is missing是同一套哲学的 TypeScript 表达。九、测试目录结构规范规则文件给出了明确的目录约定测试与源码分层一一对应test/ ├── unit/ │ ├── domain/ │ │ └── usecases/ │ └── data/ │ └── repositories/ ├── widget/ │ └── presentation/ │ └── pages/ └── golden/ └── widgets/ integration_test/ └── flows/ ├── login_flow_test.dart └── checkout_flow_test.dart这一结构与 patterns 规则 中的 Clean Architecture 分层domain纯 Dart /data仓储实现 /presentationWidget 与状态管理严格对齐unit/domain、unit/data分别测试用例与仓储widget/presentation测试页面golden/widgets测试视觉组件integration_test/flows承载端到端用户流程。仓库中的 Flutter 测试命令 给出了对应的定点运行方式例如flutter test test/unit/domain/usecases/get_user_test.dart。十、覆盖率门槛与 CI 阻断规则文件对覆盖率提出硬性要求业务逻辑领域层 状态管理器行覆盖率 ≥ 80%所有状态迁移必须有测试加载中 → 成功、加载中 → 错误、重试等路径全覆盖执行flutter test --coverage通过覆盖率报告器查看lcov.info覆盖率低于阈值时 CI 必须阻断。仓库中的证据相互印证common 层测试规范 同样将最低覆盖率 80%列为通用强制要求并规定 TDD 工作流先写测试 RED → 运行确认失败 → 最小实现 GREEN → 重构 IMPROVE → 验证覆盖率 80%Flutter 测试命令 的示例会话展示了覆盖率基线如 84.2%目标 80%如何作为测试运行报告的最终验收指标状态迁移全覆盖这一点在 Flutter/Dart 代码评审技能 的测试检查清单中被列为硬性条目所有状态迁移都有对应测试loading → success, loading → error, retry, empty。十一、落地实操把规范接进日常工具链测试规范不是孤立文档ECC 仓库为它配套了一整条工具链让规则可以被执行11.1 提交前检查来自 hooks 规则dart format --set-exit-if-changed . dart analyze --fatal-infos flutter test11.2 日常常用命令# 全部测试 flutter test 21 # 带覆盖率 flutter test --coverage 21 # 运行单个测试文件 flutter test test/unit/domain/usecases/get_user_test.dart 21 # 按名称模式筛选如所有 CartBloc 测试 flutter test --name CartBloc 21 # 集成测试需要真机/模拟器 flutter test integration_test/ 21 # 有意的视觉变更后更新黄金文件 flutter test --update-goldens 2111.3 自动化的编辑后格式化可选在~/.claude/settings.json中配置 PostToolUse Hook编辑.dart文件后自动执行dart format{ hooks: { PostToolUse: [ { matcher: { tool_name: Edit, file_paths: [**/*.dart] }, hooks: [ { type: command, command: dart format $CLAUDE_FILE_PATHS } ] } ] } }11.4 Agent 与技能支持排障与 TDD 兜底当测试失败时common 层测试规范 要求主动调用tdd-guideAgent 排查先检查测试隔离与 Mock 正确性再决定是修实现还是修测试自动化测试执行/flutter-test命令commands/flutter-test.md可以运行测试套件、按类型解析失败原因、逐个增量修复并复跑验证评审兜底合并前由 flutter-reviewer Agent 按评审清单核查状态管理器变更是否有对应单元测试、新 Widget 是否有 Widget 测试、设计关键组件是否有黄金测试、状态迁移是否全覆盖等条目并与 flutter-dart-code-review 技能中的完整测试检查清单配合使用。十二、常见失败模式速查结合 Flutter 测试命令 中沉淀的典型失败与修复路径整理如下失败现象典型修复Expected: X Actual: Y修正断言或修复实现Widget not found修正 Finder 选择器Widget 改名后同步更新测试Golden file not found运行flutter test --update-goldens生成基准图Golden mismatch检查差异若为有意变更则--update-goldensMissingPluginException在测试 setup 中 Mock 平台通道LateInitializationError在setUp()中初始化late字段pumpAndSettle timed out替换为显式pump(Duration)调用结语ECC 的 Dart/Flutter 测试规则英文原版、日文版与 common 层规范、patterns 规则、Flutter 测试命令 共同构成了一套规范定义 → 目录约束 → 命令执行 → Agent 评审的闭环测试工程体系。实践落地的要点可以浓缩为五句话单元测试覆盖全部业务逻辑与状态管理器Fake 优先于 Mock复杂依赖一律手写可控替身Widget 与黄金测试守护界面行为与像素级设计状态迁移加载/成功/错误/重试必须全部有测试业务逻辑行覆盖率不低于 80% 且由 CI 强制阻断。照着这套规范执行你的 Dart/Flutter 项目将同时获得可维护性、可回归性与可审查性三重保障。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考