单元测试中Mock的正确用法及第三方依赖测试疑问

1. 关于getAirQualityIndex方法的Mock策略 #

• 必须Mock的部分：第三方API的HttpResponse相关调用（statusCode()、body()）。单元测试要避免真实调用外部API——这会让测试依赖网络、第三方服务可用性，导致测试不稳定、执行慢，也无法模拟异常场景（比如500错误、超时）。
• 无需Mock的部分：ObjectMapper.readValue()。Jackson是成熟的序列化库，你不需要测试它的功能，反而应该用真实的ObjectMapper来验证你的代码是否能正确将第三方返回的JSON转换为业务对象。
• 测试的实际意义：不止是验证状态码判断逻辑，而是覆盖多种场景：
  • 模拟statusCode()返回200，配合提前准备的合法JSON，断言生成的业务对象字段与JSON完全匹配；
  • 模拟statusCode()返回404/500，断言方法是否抛出预期的异常或返回正确的错误标识；
  • 模拟body()返回格式错误的JSON，断言方法是否能正确处理解析失败的情况（比如抛异常、返回默认对象，取决于你的代码逻辑）。

2. 关于writeAirQualityIndexAsPdf方法的测试方案 #

这类以调用第三方库为主的方法，核心测试点是你是否正确将业务数据映射到PDF的对应内容中，不需要Mock所有itext7调用，推荐用真实库做"轻量端到端"的单元测试：

• 生成PDF到内存流（比如ByteArrayOutputStream），避免磁盘IO开销；
• 用itext7的PdfReader读取生成的PDF，提取文本内容；
• 断言PDF中包含业务对象的关键数据：比如空气质量指数数值、城市名称、监测时间等。
• 示例流程：构造一个测试用的AirQuality对象 → 调用writeAirQualityIndexAsPdf生成内存PDF → 读取PDF文本 → 检查是否存在"空气质量指数：85"、"监测城市：上海"等预期内容。

3. 正确的Mock使用原则 #

Mock的核心目的是隔离不稳定的外部依赖，而非"所有第三方调用都要Mock"：

• 要Mock的是：第三方API、数据库、消息队列、文件系统这类依赖外部环境的服务，它们会让测试不可控；
• 不要Mock的是：成熟的通用类库（比如Jackson、itext7、Guava等），你的代码只是调用它们的API完成通用功能，测试的重点是你是否正确传递了业务数据，而非验证这些库的功能；
• 单元测试的本质是测你的代码逻辑：要么测你如何处理外部依赖的不同返回，要么测你如何把业务数据转换为第三方库的输出产物。

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