测试与替换点

本页记录 Flutter 前端当前已经存在的测试护栏，以及哪些依赖点已经设计成可替换、可注入。

结论

当前前端测试体系已经覆盖：

api/ contract tests
bloc/ 单元测试
screens/ widget tests
widgets/ widget tests
integration/ 流程测试
config/theme/ 与 utils/ 测试

这意味着后续前端改动并不是“完全裸奔”，而是已经有一套相对成熟的替换与验证结构。

主要替换点

替换点	当前形式	用途
`Dio` 注入	client 构造参数支持 `dio`	API 测试、拦截器验证、伪响应注入
`http.Client` 注入	client 构造参数支持 `httpClient`	assessment / user 等 API 替换
`FlutterSecureStorage` 注入	bloc / client 构造参数支持 `secureStorage`	token、缓存、鉴权链路测试
`multipartRequestFactory` 注入	`UserApiClient` 暴露 factory	文件上传 / 头像上传链路测试
BLoC 依赖注入	`AuthBloc`、`ChatBloc`、`ExerciseBloc` 等可注入 client	bloc 层单测与状态验证
页面 builder / bloc 注入	如 `SplashScreen` 可注入 `SplashBloc`、`homeBuilder`、`loginBuilder`	screen 行为测试

关键 contract tests

`replacement_point_contract_test.dart`

该测试已经明确验证以下替换点：

ChatApiClient 使用注入的 Dio 与 secure storage
AssessmentApiClient 使用注入的 http.Client
UserApiClient 使用注入的 http.Client
CompanionApiClient 使用注入的 Dio 与 secure storage
UserApiClient 支持注入 multipartRequestFactory

这说明前端的“可替换接口”不是文档想象，而是有测试兜底的。

测试分层

目录	当前覆盖重点
`test/api/`	API client 行为、替换点 contract
`test/bloc/`	BLoC 状态流、依赖注入、校验逻辑
`test/screens/`	screen 级渲染与交互
`test/widgets/`	细粒度组件行为
`test/integration/`	跨页面流程、UI 一致性
`test/config/`	theme / animation 等配置级测试
`test/utils/`	纯工具逻辑

关键测试样本

测试文件	作用
`test/api/replacement_point_contract_test.dart`	API 替换点 contract
`test/bloc/chat/chat_bloc_injection_test.dart`	`ChatBloc` 注入 `ChatApiClient`
`test/screens/chat/chat_screen_test.dart`	ChatScreen UI 主体与欢迎态
`test/screens/home/home_layout_test.dart`	首页布局结构
`test/screens/exercise/exercise_execution_screen_test.dart`	运动执行页行为
`test/screens/splash/splash_screen_test.dart`	启动分流页行为
`test/integration/exercise_feedback_flow_test.dart`	运动反馈整链路
`test/integration/ui_consistency_test.dart`	UI 一致性护栏

对交接最有价值的测试，通常不是数量最多的那一批，而是最能说明边界的那一批：

replacement_point_contract_test.dart：说明前端依赖替换点不是口头约定。
chat_bloc_injection_test.dart：说明 bloc 层可以脱离真实网络进行替换验证。
chat_screen_test.dart、home_layout_test.dart：说明关键页面的基础结构已有自动化护栏。

当前工程判断

1. 前端已经具备注入友好的基础

不是所有模块都做到了理想 DI，但关键 client 与 bloc 已可注入。
这对后续 refactor、mock、回归验证很重要。

2. 测试面分布比较健康

不只测 API
也不只测 widget
而是形成了从 client 到 bloc 到 screen 到 integration 的多层覆盖

3. 仍需谨慎的地方

ExerciseBloc 这类依赖较重的 bloc 需要关注 mock 数据与真实 API 的边界
SettingsScreen 这类局部 state 页面虽然易测，但当前并不是注入式设计的重点区域

变更验证建议

变更区域	优先验证
API client	对应 `test/api/*`，尤其是替换点、token、错误分支
BLoC 状态流	对应 `test/bloc/*`，验证事件到状态的完整转换
主页面结构	`test/screens/*` 或 widget test，确认关键控件和状态渲染存在
运动执行 / 反馈	`test/integration/exercise_feedback_flow_test.dart` 等链路测试
视觉 token / 组件	`test/integration/ui_consistency_test.dart` 与组件级测试
隐藏入口页维护	保留原有测试价值，但不要用测试存在证明页面当前可达

来源锚点

apps/flutter_app/test/api/replacement_point_contract_test.dart
apps/flutter_app/test/bloc/chat/chat_bloc_injection_test.dart
apps/flutter_app/test/screens/chat/chat_screen_test.dart
apps/flutter_app/test/integration/
apps/flutter_app/test/widgets/