Flutter项目中Mock文件（含自动生成文件）存储位置的最佳实践

针对Mockito通过@generateMocks注解自动生成的Mock文件，Flutter社区常用以下几种存储方案，各有优劣：

方案1：Mock文件与对应测试代码同目录存放 #

将每个Mock文件保存在依赖它的测试包/目录中，比如测试lib/src/user/user_repo.dart的代码放在test/src/user/user_repo_test.dart，对应的Mock就生成在该目录下。

优点 #

• 关联性直观：测试代码和依赖的Mock放在一起，查找、修改时无需跨目录跳转
• 无冗余生成：仅为当前测试模块需要的类生成Mock，避免无用文件
• 隔离性强：不同模块的Mock互不影响，修改某模块Mock不会波及其他测试

缺点 #

• 重复代码：多个测试模块依赖同一类的Mock时，会重复生成相同的Mock文件，增加项目代码量
• 维护成本高：若需修改某类Mock的生成规则（比如添加自定义方法），要在所有用到该Mock的测试目录中逐一修改注解

方案2：创建全局Mock包统一存储 #

在项目中单独创建一个专门存放所有Mock的包（比如test/mocks），统一生成和管理所有需要的Mock文件。

优点 #

• 集中维护：所有Mock统一存放，修改生成规则只需操作一处，减少重复劳动
• 复用性高：多个测试模块可直接引用同一Mock，避免重复生成
• 结构清晰：测试代码与Mock代码分离，项目整体架构更规整

缺点 #

• 关联性弱：测试代码和Mock文件不在同一目录，查找时需要跨目录定位，不够直观
• 冗余风险：可能生成大量实际用不到的Mock文件，增加项目体积
• 耦合性高：全局Mock包会依赖多个业务模块的类，一旦业务类结构变更，需要同步更新全局Mock的生成规则

方案3：混合模式（通用Mock全局存，专属Mock随测试放） #

将项目中的Mock分为两类处理：

• 通用核心类（比如Dio、SharedPreferences、全局基础服务类）的Mock放在全局Mock包统一管理
• 业务模块专属类（比如某页面ViewModel、特定业务Repository）的Mock随对应测试代码存放

优点 #

• 兼顾复用与直观：既减少通用Mock的重复生成，又保证模块Mock的独立性和易查找性
• 平衡冗余与维护：避免全局Mock包的冗余问题，同时降低模块Mock的维护成本

缺点 #

• 初期规划成本：需要明确划分通用类和专属类的界限，否则容易出现归类混乱
• 规则模糊风险：部分类的归属难以界定，可能导致存储方式不一致

Flutter专属建议 #

结合Flutter默认的项目结构（lib存业务代码，test存测试代码），优先推荐混合模式：

1. 全局Mock配置：在test/mocks目录下创建入口文件（比如mock_generators.dart），通过@generateMocks注解声明所有通用核心类的Mock生成规则，配置build_runner将生成文件输出到test/mocks/generated子目录，避免与配置文件混放。
2. 模块Mock配置：针对业务模块的专属类，直接在对应测试目录下创建mock.dart文件，添加@generateMocks注解生成Mock，输出到该目录的generated子目录。
3. 配合Mockito技巧：使用@GenerateMocks的customMocks参数，为全局Mock设置通用默认行为，为模块Mock定制测试所需的特定行为。

内容的提问来源于stack exchange，提问作者sharbel okzan