做打印扫描类软件时，经常遇到测试覆盖率卡在 75% 上不去——明明功能都跑通了，但单元测试一跑，覆盖率报告红得扎眼。别急着改代码，先看看是不是这几个地方漏了。
1. 打印驱动回调函数常被忽略
比如调用 Windows Print Spooler API 后注册的 JobStatusCallback，或者 Linux 下 CUPS 的 ipp_status_t 处理分支。这些回调往往只在真实打印任务中触发，单元测试里不模拟就永远不执行。
解法：用 mock 框架伪造 IPP 响应或重写本地 spooler 调度逻辑。例如在 Jest（Node.js 打印服务）中：
jest.mock('cups', () => ({
getJobs: jest.fn().mockResolvedValue([
{ id: 123, state: 'completed', status: 0 }
]),
getStatus: jest.fn().mockReturnValue({ code: 0 })
}));2. 扫描异常路径压根没走
扫描仪断连、纸张卡住、TWAIN 驱动初始化失败……这些报错逻辑写了，但测试时总用正常设备跑，错误分支从没进过。覆盖率工具自然标为“未覆盖”。
动手试一次：拔掉扫描仪 USB 线，再运行扫描接口测试。如果直接崩了，说明异常处理没兜住；如果静默跳过，说明日志或提示缺失，也该补上断言。
3. 配置文件读取和默认值逻辑太“安静”
像 scan.conf 或 printer-profile.json 里缺字段时的 fallback 行为，往往只有在删掉某项配置后才触发。但日常开发几乎不删，结果这部分代码常年灰着。
建议在测试前临时改配置：
// 测试前
fs.writeFileSync('scan.conf', JSON.stringify({
resolution: 300,
// color_mode 字段故意删掉
}));
// 再运行 scan.start()
// 触发 color_mode 默认设为 'grayscale' 的逻辑4. 别硬刷覆盖率数字
有团队为了达标，给空 catch 块加一行 console.log('ignored') 再测一遍——这反而埋雷。打印扫描场景里，真正的风险点是：双面扫描翻页错位、PDF 元数据丢失、中文路径下文件名乱码。优先把这几类 case 的测试写全，哪怕覆盖率只到 68%，也比 85% 的“假绿条”靠谱。
实在卡在某个函数，打开覆盖率报告，点进去看哪几行红着。如果是设备无关的纯逻辑（比如 DPI 换算公式），补个边界值测试；如果是平台相关（如 macOS 的 ImageCaptureCore 初始化），那就记进 TODO，等真机测试环境搭好再补。