答案是使用unittest的assertRaises和assertRaisesRegex方法捕获预期异常，验证异常类型及消息，确保错误处理逻辑正确。通过上下文管理器获取异常实例，可进一步检查异常属性，提升测试的精确性和代码可靠性。
在Python的unittest框架中，捕获代码运行时可能抛出的异常，并将其作为测试通过的条件，是验证程序健壮性和错误处理逻辑的关键技巧。核心观点在于，我们并非总是期望代码平稳运行，有时，在特定输入或状态下，代码“正确地”抛出异常本身就是我们想要测试的行为。unittest为此提供了专门的断言方法，让我们能够优雅地验证这些预期中的异常。
解决方案
unittest框架主要通过self.assertRaises()和self.assertRaisesRegex()这两个方法来捕获和验证预期异常。它们既可以作为上下文管理器使用，也可以直接调用。通常，我更倾向于使用上下文管理器形式，因为它能让代码更清晰，并且能让我们在异常被捕获后，进一步检查异常对象本身。
例如，假设我们有一个函数，当输入不合法时会抛出ValueError：
def divide(a, b):
if b == 0:
raise ValueError("除数不能为零")
return a / b
import unittest
class TestDivision(unittest.TestCase):
def test_divide_by_zero(self):
# 使用上下文管理器捕获预期的ValueError
with self.assertRaises(ValueError) as cm:
divide(10, 0)
# 此时，cm.exception就是被捕获的ValueError实例
self.assertEqual(str(cm.exception), "除数不能为零")
def test_divide_by_zero_regex(self):
# 如果想更灵活地匹配异常消息，可以使用assertRaisesRegex
with self.assertRaisesRegex(ValueError, "不能为零") as cm:
divide(10, 0)
self.assertIn("不能为零", str(cm.exception))
def test_no_exception(self):
# 验证正常情况不抛异常
self.assertEqual(divide(10, 2), 5)
if __name__ == '__main__':
unittest.main(argv=['first-arg-is-ignored'], exit=False)通过这种方式，我们不仅确认了异常的类型，甚至能进一步验证异常消息是否符合预期，这对于确保用户友好的错误提示或内部错误码的准确性至关重要。
立即学习“Python免费学习笔记（深入）”；
在测试中验证异常：为何这比简单失败更有价值？
在软件开发中，我们常常谈论“防御性编程”，其核心思想之一就是预判并妥善处理各种异常情况。一个健壮的系统，在面对无效输入、资源不足或权限问题时，不应该只是崩溃，而应该以可预测的方式失败，并提供有意义的反馈。这时，测试代码能够“正确地”抛出异常，就显得尤为重要。
如果我们的代码在特定条件下确实应该抛出ValueError，那么在测试中，我们期望的不是程序平稳运行，而是它能够按照设计抛出这个ValueError。如果只是简单地让测试失败（因为没有捕获异常），那么我们得到的反馈仅仅是“代码出错了”，而不是“代码按照预期处理了错误”。这两种情况的意义天差地别。前者可能指向一个bug，而后者则确认了一个功能——即错误处理功能——是正常工作的。
所以，通过assertRaises来验证异常，实际上是在测试程序的错误处理逻辑是否正确、是否完备。这就像测试一个安全门，我们不仅要测试它在正常情况下能否打开，更要测试它在非法入侵时能否正确地触发警报。这不仅提升了代码的可靠性，也为后续的维护和调试提供了清晰的指引。
assertRaises 和 assertRaisesRegex：用法与选择考量
这两种方法是unittest处理异常测试的核心工具，但它们各有侧重。
*`self.assertRaises(expected_exception, callable_obj, args, kwargs)`
或者更推荐的上下文管理器形式：
with self.assertRaises(expected_exception) as cm:
- 用途: 主要用于验证被测代码是否抛出了特定类型的异常。
-
参数:
-
expected_exception: 期望捕获的异常类型（例如ValueError、TypeError）。 -
callable_obj: （可选）一个可调用对象，如函数名或方法名。如果提供，unittest会调用它并捕获其抛出的异常。 -
*args, **kwargs: （可选）传递给callable_obj的参数。
-
-
上下文管理器优势: 当作为上下文管理器使用时，
as cm会捕获并存储被抛出的异常实例到cm.exception中。这允许我们对异常对象进行进一步的检查，比如验证异常消息、错误码或自定义属性。
*`self.assertRaisesRegex(expected_exception, expected_regex, callable_obj, args, kwargs)`
或者上下文管理器形式：
with self.assertRaisesRegex(expected_exception, expected_regex) as cm:
- 用途: 除了验证异常类型，还能验证异常消息是否符合特定的正则表达式模式。
-
参数:
-
expected_regex: 一个正则表达式字符串，用于匹配异常的字符串表示（通常是异常消息）。
-
-
何时选择: 当异常消息可能包含动态内容（如文件名、变量值）或者我们只需要验证消息中的某个关键部分时，
assertRaisesRegex就显得非常有用。它提供了更灵活的匹配能力，避免了对精确字符串匹配的过度依赖。
选择考量:
一般而言，如果只需要确认异常类型，assertRaises就足够了。但如果异常消息的特定内容对验证逻辑至关重要，或者异常消息本身是动态生成的，那么assertRaisesRegex是更好的选择。在大多数情况下，我个人更倾向于使用上下文管理器形式，因为它提供了对异常对象的直接访问，使得后续的精细验证成为可能，这在测试自定义异常或包含复杂信息的异常时尤其有用。
捕获异常后，如何更细致地验证异常内容？
仅仅确认异常类型和消息模式有时还不够，尤其是在处理自定义异常或那些携带丰富上下文信息的标准异常时。通过assertRaises或assertRaisesRegex的上下文管理器形式，我们可以获取到被捕获的异常实例，进而深入验证其内部属性。
假设我们定义了一个自定义异常，用于表示API请求失败，并包含一个状态码：
class ApiException(Exception):
def __init__(self, message, status_code):
super().__init__(message)
self.status_code = status_code
def fetch_data(url):
if "error" in url:
raise ApiException("Failed to fetch data", 404)
if "auth_fail" in url:
raise ApiException("Authentication required", 401)
return {"data": "some data"}
import unittest
class TestApi(unittest.TestCase):
def test_api_data_not_found(self):
with self.assertRaises(ApiException) as cm:
fetch_data("http://example.com/error")
# 验证异常类型
self.assertIsInstance(cm.exception, ApiException)
# 验证异常消息
self.assertEqual(str(cm.exception), "Failed to fetch data")
# 验证自定义属性
self.assertEqual(cm.exception.status_code, 404)
def test_api_auth_fail(self):
with self.assertRaisesRegex(ApiException, "Authentication required") as cm:
fetch_data("http://example.com/auth_fail")
self.assertEqual(cm.exception.status_code, 401)
if __name__ == '__main__':
unittest.main(argv=['first-arg-is-ignored'], exit=False)在这个例子中，cm.exception是一个ApiException实例。我们可以直接访问它的status_code属性，并使用self.assertEqual()进行断言。这种细致的验证方法确保了：
- 异常类型正确: 确保抛出的确实是我们预期的异常类。
- 异常消息准确: 验证用户或日志中显示的错误信息是否清晰、符合预期。
- 自定义属性值正确: 对于包含额外数据的自定义异常，这能验证这些数据是否被正确设置。例如，错误码、关联的ID、堆栈信息等。
通过这种方式，我们的异常测试不再是简单的“有没有抛异常”，而是深入到“抛出的异常是否完整、准确地表达了错误信息和上下文”，这无疑让测试更具价值和说服力。它帮助我们构建出不仅能处理错误，还能以结构化、可编程的方式报告错误的系统。
