document.writeln('');

当前位置：首页 > 云服务器

解决Python单元测试中Mock异常方法调用计数为零的问题

游戏科技网2026年09月15日 03:30云服务器50

本教程深入探讨了在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。

baidu-map-jsapi-three

使用 MapV-Three 构建专业的 3D 地图和 GIS 应用 - 基于 Z-up 坐标系的 3D 地图库，支持地图编辑、测量工具、要素绘制、数据管理等地理可视化功能。适用于创建地图编辑器、测量工具、空间数据可视化等 Web-GIS 应用。

下载

理解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为零的困惑，并编写出更准确、更可靠的单元测试。