一、按「垂直切片」来开发

将一个完整的功能（Feature）作为最小单元，一次开发、一次测试、一次 UI 验证。例如“加载成员列表”这个切片，流程如下：

领域 + 仓库接口

  • 定义 MemberEntity 和 MemberRepository 接口。

Data 层 + 映射 + RepoImpl

  • 创建 MemberDto、映射逻辑以及 MemberRepositoryImpl。
  • 编写集成/单元测试，验证 JSON → DTO → Entity。

UseCase

  • 实现 LoadMembersUseCase，并立即编写两个测试：
    • 正常返回列表。
    • 异常分支（仓库抛错）。

ViewModel

  • 编写 MembersViewModel.load()，并立即测试：
    • 成功时状态从 loading → data。
    • 异常时状态变为 error。

UI

  • 在页面中消费 ViewModel。
  • 进行简单的手动验收，或编写轻量级的 Widget Test（可选）。

这种方式确保每个 Layer 的核心逻辑完成后立即测试并确认，再继续 UI 开发，避免出现“核心逻辑未完成”或“UI开发中后端逻辑变更”的问题。

二、测试要集中在“有业务逻辑的地方”

  • 必写：UseCase、复杂的 Mapper/转换、ViewModel 的状态机。
  • 可选：简单的 DTO、纯 UI 布局（手动验收或少量 Widget Test）。
  • 不覆盖：简单的 Getter/Setter、无分支的一行方法。

这样既能保护核心场景，又避免浪费精力在简单工具函数的测试上。

三、并行而非串行

可以同时进行 UseCase 测试和 UI 开发：

1
2
3
if (state.isLoading) showSpinner();
else if (state.isError) showError();
else showList(state.members);
  • UseCase 和 ViewModel 的测试先跑通。
  • UI 开发可以使用假数据或 Mock ViewModel 先行搭建，再接入真实逻辑。

四、典型节奏

  1. 先踩“刀”：编写 UseCase 和测试，确保业务逻辑正确。
  2. 再搭“台”：在 ViewModel 和 UI 上挂载 UseCase，初步展示页面。
  3. 再补“细节”：完善边界场景、多分支测试、Widget Test 或手动验收。

通过这种小循环的迭代方式，功能开发、测试覆盖和 UI 成型可以同步完成。

小结

  • 不必等到“每个函数都写完测试”，避免 UI 开发被测试进度拖慢。
  • 按切片并行开发：完成一个小功能的 Domain → Data → Application → Presentation，测试和 UI 同步进行。
  • 聚焦业务逻辑：测试核心场景，UI先手动验收，再补充 Widget Test。

这种迭代式、切片驱动的开发方式既能保证测试覆盖，又能确保 UI 开发与后端逻辑进度保持一致。