本教程深入探讨了在python单元测试中使用`unittest.mock`模拟类方法抛出异常时，`call_count`意外为零的常见困惑。文章将阐明`patch`类时，方法调用计数应针对模拟的实例对象而非模拟类本身，并通过详尽的代码示例和解释，指导开发者正确地设置`side_effect`并断言方法调用，确保测试逻辑的准确性。
在编写单元测试时，我们经常需要模拟（mock）外部依赖的行为，包括模拟这些依赖抛出异常的情况。unittest.mock库是Python中实现这一目标的强大工具。然而，在使用patch来模拟一个类及其方法，并期望该方法抛出异常时，开发者可能会遇到一个令人困惑的问题：即使方法确实被调用并成功抛出异常（且异常可能被捕获），其call_count却显示为0。本文将深入分析这一现象的根本原因，并提供正确的解决方案。
问题场景描述
考虑一个服务类UploadService，其中包含一个upload方法，该方法内部调用了Blob类的一个实例方法upload_from_string。我们希望测试当upload_from_string方法抛出异常时，UploadService的异常处理逻辑是否正确。
以下是相关的代码示例：
upload_service.py
立即学习“Python免费学习笔记（深入）”；
import json
import logging
# 假设这些是外部库的类和异常
class GoogleCloudError(Exception):
pass
class Blob:
def __init__(self, name, bucket):
self.name = name
self.bucket = bucket
def upload_from_string(self, data, content_type):
"""模拟上传文件到云存储"""
# 实际实现可能包含与云服务交互的逻辑
print(f"Uploading {self.name} to {self.bucket} with data: {data}")
# 这里为了模拟，不实际上传
class UploadService:
def __init__(self, bucket_name):
self.bucket_name = bucket_name
def upload(self, name, data):
try:
# 实例化 Blob 对象
gcs_blob = Blob(name, self.bucket_name)
# 调用实例方法
gcs_blob.upload_from_string(data=json.dumps(data), content_type="application/json")
return "Upload successful"
except GoogleCloudError as e:
logging.exception(f"Error uploading file '{name}' to '{self.bucket_name}'")
return f"Upload failed: {e}"
test_upload_service.py (原始的、有问题的测试)
import unittest
from unittest.mock import patch, Mock
from upload_service import UploadService, Blob, GoogleCloudError
class TestUploadService(unittest.TestCase):
def test_upload_failure(self):
us = UploadService("my-test-bucket")
test_data = {"key": "value"}
test_name = "test-file.json"
with patch("upload_service.Blob") as MockedBlobClass:
# 获取模拟的 Blob 实例
gcs_blob_instance = MockedBlobClass.return_value
# 设置实例方法在调用时抛出异常
gcs_blob_instance.upload_from_string.side_effect = GoogleCloudError("Google Cloud upload failed")
# 调用待测试的方法
result = us.upload(test_name, test_data)
# 断言异常被处理
self.assertIn("Upload failed", result)
# 错误的断言：尝试在 MockedBlobClass 上检查 call_count
# 预期这里是1，但实际是0
self.assertEqual(1, MockedBlobClass.upload_from_string.call_count)
运行上述测试，会得到如下错误：
AssertionError: 1 != 0 Expected :1 Actual :0
这表明尽管side_effect被正确触发，并且异常被捕获，但MockedBlobClass.upload_from_string.call_count却为0。
理解unittest.mock.patch对类的作用
问题的核心在于对unittest.mock.patch如何模拟类的理解。当使用patch("module.ClassName")时，MockedClassName实际上是一个模拟的类对象。这意味着：
- MockedClassName本身是一个Mock对象：它可以被调用，其call_count会记录对类构造函数的调用次数。
- MockedClassName.return_value是该类的模拟实例：当被测试的代码（SUT）通过ClassName(...)来实例化一个对象时，patch会拦截这个调用，并返回MockedClassName.return_value这个Mock对象。这个MockedClassName.return_value才是SUT中实际操作的“实例”。
- 方法调用发生在实例上：在我们的例子中，gcs_blob = Blob(...)会返回MockedBlobClass.return_value。随后，gcs_blob.upload_from_string(...)是在这个模拟实例上调用的方法，而不是在模拟类MockedBlobClass上调用的。
因此，MockedBlobClass.upload_from_string实际上是一个从未被调用的Mock对象，因为它代表的是“类方法”或“未实例化的类上的方法”。而真正被调用的是MockedBlobClass.return_value.upload_from_string。
正确的断言方式
要解决这个问题，我们需要将call_count的断言指向正确的Mock对象，即模拟的实例对象的方法。在我们的测试代码中，gcs_blob_instance就是这个模拟的实例对象。
以下是修正后的测试代码：
test_upload_service.py (修正后的测试)
import unittest
from unittest.mock import patch, Mock
from upload_service import UploadService, Blob, GoogleCloudError
class TestUploadService(unittest.TestCase):
def test_upload_failure_corrected(self):
us = UploadService("my-test-bucket")
test_data = {"key": "value"}
test_name = "test-file.json"
with patch("upload_service.Blob") as MockedBlobClass:
# 获取模拟的 Blob 实例
gcs_blob_instance = MockedBlobClass.return_value
# 设置实例方法在调用时抛出异常
gcs_blob_instance.upload_from_string.side_effect = GoogleCloudError("Google Cloud upload failed")
# 调用待测试的方法
result = us.upload(test_name, test_data)
# 断言异常被处理
self.assertIn("Upload failed", result)
# 正确的断言：在模拟的实例方法上检查 call_count
self.assertEqual(1, gcs_blob_instance.upload_from_string.call_count)
# 也可以通过 MockedBlobClass().upload_from_string 来访问，效果相同
# self.assertEqual(1, MockedBlobClass().upload_from_string.call_count)
通过将断言从MockedBlobClass.upload_from_string.call_count改为gcs_blob_instance.upload_from_string.call_count，测试将成功通过。这是因为gcs_blob_instance正是UploadService.upload方法中实际操作的Blob实例的模拟。
注意事项与最佳实践
- 区分模拟类与模拟实例：当patch一个类时，要清楚地认识到patched_class是模拟类，而patched_class.return_value（或patched_class()）是模拟实例。所有对实例方法的调用和属性的访问都应该通过模拟实例进行。
- 设置side_effect和断言call_count的一致性：如果你在模拟实例的方法上设置了side_effect，那么也应该在该模拟实例的方法上检查call_count、called、call_args等属性。
- 代码可读性：为了提高测试代码的可读性，建议将MockedBlobClass.return_value赋值给一个有意义的变量名（如gcs_blob_instance），这样可以更清晰地表达你正在操作的是一个模拟的实例。
- 异常与call_count无关：方法是否抛出异常，或者异常是否被捕获，都不会影响其call_count。只要方法被调用，call_count就会递增。问题不在于异常，而在于断言的目标错误。
总结
在Python单元测试中使用unittest.mock.patch模拟类及其方法时，正确理解模拟类和模拟实例之间的区别至关重要。当被测试代码实例化一个类并调用其方法时，方法调用实际上发生在模拟的实例对象上。因此，设置side_effect和断言call_count都应针对这个模拟实例的方法。遵循这些原则，可以避免常见的call_count为零的困惑，并编写出更准确、更可靠的单元测试。
