如何编写单元测试模拟中断验证Python程序数据一致性
不需要修改业务代码插入测试用的抛错语句，也不需要劫持修改Python解释器，针对你要覆盖低层级执行位置、模拟真实断电中断的需求，有两类成熟的落地方案：
系统调用层故障注入（最贴近真实断电场景）
真实断电、进程被强杀的本质，是程序执行到任意位置时直接被销毁，不会执行任何Python层的finally逻辑、上下文管理器清理逻辑，绝大多数持久化中断都发生在IO相关的系统调用阶段。
你可以用LD_PRELOAD机制挂钩目标进程的write、fsync、rename等和持久化相关的系统调用，设置计数触发规则：当程序第N次调用目标系统调用时，直接向进程发送SIGKILL信号强杀，这种拦截发生在C语言层级，不管是你的业务Python代码、还是Python解释器内部的C实现逻辑执行到对应位置，都能精准触发中断，完全不需要改动业务代码。
实际测试时按如下流程执行即可：- 初始化故障计数为1
- 启动待测试的Python程序，挂载系统调用钩子，配置为计数到当前值时强杀进程，触发持久化流程
- 进程被杀死后，重新加载持久化数据，校验一致性：数据要么是完整的持久化前版本，要么是完整的新版本，不存在半写损坏、结构错乱的问题
- 故障计数加1，重复上述流程，直到计数覆盖整个持久化流程的所有系统调用点、程序可以完整跑完持久化逻辑为止
注意不要用Python层普通的raise语句模拟中断，这类异常会触发所有注册的清理逻辑，和真实断电的表现完全不符，测试结果没有参考价值。
字节码动态插桩（覆盖Python层任意执行点）
如果你需要覆盖非IO阶段的Python代码执行位置，可以在测试代码中用sys.settrace实现动态插桩，不需要在业务源码里加任何测试逻辑：给待测试的持久化函数注册trace回调，每执行指定条数的Python字节码，就直接调用os._exit(1)强制终止进程。os._exit()会直接退出进程，不会执行任何清理逻辑，和硬中断表现一致，这种方式可以覆盖到Python代码执行的每一个字节码节点，精度远高于手动在高层代码间隙插抛错语句。前置逻辑校验
所有故障注入测试之前，先确认你的持久化逻辑符合原子写规范：先写入独立的临时文件，调用fsync确保临时文件内容真正落盘，再调用os.rename原子替换正式文件。本地文件系统的rename操作是原子的，只要遵循这个范式，才能从根本上保证任意时刻中断都不会出现不一致的损坏数据。
内容的提问来源于stack exchange，提问作者mtanti
