如何为数据存储与读取函数编写规范的单元测试

问题1：存储格式变更导致测试失败是否正常？ #

直接读取文件验证save_data()的正确性，本质是绑定了序列化格式、文件写入这类实现细节，而非测试save_data的核心职责——“正确完成数据持久化”。当存储格式变更但get_data()同步适配后，对外接口的契约（存入的数据能完整取出）是成立的，但你的测试硬编码了旧格式的校验规则，才会出现“无问题却失败”的情况。

这种情况不正常，好的单元测试应该聚焦函数对外承诺的行为，而非内部实现细节。

问题2：把save和get放在同一测试里是否可行？ #

单个测试用例同时测试save_data()和get_data()，本质是验证数据持久化的闭环正确性——存入的数据能被正确取出。这是合理的测试场景，尤其当两个函数共同构成“数据持久化”核心功能时。

所谓“不应在单个测试中测试两个函数”的说法，是指避免用一个测试同时验证多个独立逻辑点，导致失败时难以定位问题。但如果这两个函数强耦合（save的输出就是get的输入），测试它们的协同行为反而更贴合实际业务。

不过这种做法也暴露了代码设计的潜在问题：

• 内部依赖不可控：save_data和get_data直接依赖底层文件操作函数，无法通过依赖注入替换，只能用真实文件系统测试，既慢又容易产生测试污染。
• 职责边界模糊：save_data同时承担“数据序列化”和“文件写入”，get_data同时承担“文件读取”和“数据解析”，职责不够单一。未来更换存储方式（比如从文件改数据库）时，这两个函数都需要大幅修改。

优化建议 #

1. 依赖注入解耦：将文件操作、序列化/解析逻辑作为参数传入，测试时用模拟对象替换真实操作：

def save_data(data, serialize_func=_serialize, write_func=_write_to_file):
    write_func(serialize_func(data))

def get_data(read_func=_read_file, parse_func=_parse_data):
    return parse_func(read_func())

测试save_data时，可传入内存存储的write_func，直接验证序列化内容；测试get_data时，传入预设内容的read_func，验证解析逻辑。

2. 拆分职责：把序列化/解析、文件操作拆成独立组件，比如DataSerializer类和FileStorage类：

• 测试DataSerializer：验证序列化与解析的双向一致性
• 测试FileStorage：验证文件读写的正确性
• 测试save_data和get_data：只需验证它们正确调用依赖组件即可

3. 保留闭环测试：除了单元测试单个组件，补充集成测试用例验证save_data+get_data的整体闭环行为，确保功能符合预期。

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