Pytest断言实战：从基础到高级的自动化测试验证技巧

1. 项目概述：为什么断言是自动化测试的“定海神针”？

干了这么多年自动化测试，我见过太多因为断言写得不好而翻车的案例。一个测试用例跑过了，页面也点了，接口也调了，最后报告显示“PASS”，结果上线后用户反馈功能是坏的。问题出在哪？十有八九是断言没写对，或者压根没写全。断言（Assert）在自动化测试里，就像是你去超市买东西后核对小票，光把东西装进购物车不算完，你得确认价格、数量、商品名称都对得上，这才算一次成功的购物。在Python的pytest框架里，assert语句就是这张“小票核对器”，它负责验证代码的实际行为是否符合我们的预期。

pytest之所以成为Python生态里测试框架的绝对主流，除了其简洁的语法和强大的插件体系，它对原生assert语句的“魔改”和增强功不可没。你不需要去记assertEquals、assertTrue、assertIn这些JUnit风格的方法名，直接用Python的assert，pytest就能给你提供极其丰富的失败信息。这对于快速定位问题至关重要。想象一下，一个复杂的对象比较失败了，如果只告诉你“AssertionError”，你可能会一头雾水；但pytest能告诉你具体是哪个字段、哪个列表的第几个元素不匹配，这种调试体验是天壤之别。

这篇总结，就是把我这些年用pytest写断言踩过的坑、总结的技巧、以及那些官方文档里不会明说但极其好用的“野路子”，系统地梳理一遍。无论你是刚开始写自动化测试的新手，还是想优化现有测试套件的老鸟，这里的内容都能让你对assert有一个全新的、更深入的认识。我们会从最基础的用法开始，一直深入到自定义断言、断言重写原理、以及在API、UI测试中的实战应用，目标是让你写的每一个断言都精准、可靠、易于维护。

2. 断言基础：从“能用”到“精通”的跨越

很多人觉得assert不就是个关键字吗，assert a == b，有什么好讲的？但恰恰是这种轻视，导致了测试用例的脆弱和不可靠。我们先来夯实基础，看看如何把一个简单的断言写出花来。

2.1 理解pytest的断言重写机制

这是pytest断言体系的核心魔法，也是它比unittest的assertEqual等方法更强大的根本原因。当你用python -m pytest运行测试时，pytest会首先对测试模块进行“重写”（Rewrite）。它会解析你的源代码，找到所有的assert语句，并将其替换为一个更复杂的表达式。这个新表达式不仅执行比较，还会在断言失败时，捕获操作数（比如a和b）的详细信息。

举个例子，你写了：

def test_addition(): result = 1 + 2 assert result == 5

直接运行这个函数，你只会得到：AssertionError。但用pytest运行，你会看到：

AssertionError: assert 3 == 5

看，它自动把result的值3给打印出来了。这还只是开始。对于更复杂的比较，比如列表：

def test_list(): a = [1, 2, 3] b = [1, 2, 4] assert a == b

pytest的输出会是：

AssertionError: assert [1, 2, 3] == [1, 2, 4] At index 2 diff: 3 != 4 Use -v to see the full diff

它甚至告诉你，是在索引2的位置发生了差异。如果你加上-v参数，它会展示完整的对比差异。这个功能对于调试数据结构错误是神器。

注意：断言重写只对通过pytest命令运行的测试文件生效。如果你直接使用python test_file.py来运行，或者文件不以test_开头、函数不以test_开头，重写机制可能不会触发，你将失去这些详细的错误信息。这是新手常踩的一个坑。

2.2 基础断言类型的实战写法

基础的比较运算符==,!=,<,<=,>,>=,in,not in,is,is not都可以直接用在assert后面。但怎么写更有可读性、更不容易出错，是有讲究的。

1. 相等与不相等断言：

# 直接比较 assert user.name == “张三” # 比较前进行预处理，更健壮 assert user.name.strip().lower() == “zhangsan” # 对于浮点数，永远不要直接用 == assert abs(0.1 + 0.2 - 0.3) < 1e-9 # 使用误差范围 # pytest提供了更优雅的方式：pytest.approx import pytest assert 0.1 + 0.2 == pytest.approx(0.3)

pytest.approx是处理浮点数比较的黄金标准，它可以处理绝对误差和相对误差，非常灵活。

2. 成员与身份断言：

# 检查元素是否在容器中 assert ‘admin’ in user.roles assert ‘guest’ not in user.permissions # 检查对象是否为None（优先使用is/is not） assert response.data is not None assert error is None # 检查两个变量是否指向同一个对象 assert obj1 is obj2 # 身份相同 assert obj1 == obj2 # 值相等（可能身份不同）

这里有个关键点：is比较的是内存地址（身份），==调用的是对象的__eq__方法（值相等）。对于None、True、False这类单例对象，一定要用is。

3. 真值断言：

# 检查布尔值 assert success is True assert not failure # 检查容器是否为空/非空（利用Python的“真值”特性） assert shopping_cart # 等价于 len(shopping_cart) > 0，购物车非空 assert not error_list # 等价于 len(error_list) == 0，错误列表为空 # 检查字符串 assert username # 非空字符串 assert not message or message.strip() # 允许为空或空白字符串

利用Python的“真值测试”（Truthiness）可以让断言更简洁。空列表[]、空字典{}、空字符串“”、None、数字0在布尔上下文中都被视为False。

2.3 为断言添加清晰的失败信息

这是提升测试可维护性的最重要技巧之一。一个光秃秃的assert失败时，你可能需要花时间看上下文才知道在验证什么。加上失败信息，就像给错误贴上了标签。

# 不推荐的写法 assert len(items) > 0 # 推荐的写法 assert len(items) > 0, f“购物车商品数量应为正，实际为 {len(items)}” assert user.is_active, f“用户 {user.id} 应该处于激活状态” assert ‘token’ in response.json(), f“响应中缺少token字段，完整响应：{response.text}”

失败信息应该清晰地说明“期望什么”和“实际是什么”。使用f-string来动态嵌入实际值，信息量最足。当这个断言在CI/CD流水线中失败时，清晰的错误信息能让排查效率提升数倍。

3. 高级断言技巧：应对复杂验证场景

当你的测试从简单的单元测试扩展到集成测试、API测试时，断言的对象会变得非常复杂：嵌套字典、对象列表、HTML片段、JSON响应。这时候，基础的assert就显得力不从心了。我们需要更强大的工具。

3.1 处理复杂数据结构：JSON与字典断言

API测试中，断言响应的JSON结构是家常便饭。直接对两个大字典用==比较，一旦失败，错误信息会非常冗长，难以阅读。我们需要更精细的控制。

策略一：逐字段断言。这是最清晰、最可控的方式，特别适合作为契约测试，确保接口返回了必需的字段和正确的类型。

def test_user_api(): response = client.get(‘/api/user/1’) data = response.json() assert response.status_code == 200 assert ‘id’ in data assert isinstance(data[‘id’], int) assert data[‘id’] == 1 assert ‘username’ in data assert isinstance(data[‘username’], str) assert len(data[‘username’]) > 0 assert ‘email’ in data # 可以验证邮箱格式 assert ‘@’ in data[‘email’] assert ‘created_at’ in data # 验证时间戳格式 assert isinstance(data[‘created_at’], str)

这种写法的优点是，任何一个字段出错，都能立刻知道是哪个字段不符合预期。缺点是代码量稍大。

策略二：使用模式匹配（如字典包含比较）。我们经常只关心响应中的部分关键字段，不关心其他字段。这时可以用字典解构或自定义函数。

# 只断言关心的字段 expected_fields = { ‘id’: 1, ‘username’: ‘zhangsan’, ‘is_active’: True } for key, expected_value in expected_fields.items(): assert data.get(key) == expected_value, f“字段 {key} 不匹配” # 或者写一个辅助函数 def assert_dict_contains(expected_subset, actual_dict): “”“断言 actual_dict 包含 expected_subset 中的所有键值对”“” for key, expected_value in expected_subset.items(): assert key in actual_dict, f“缺少键：{key}” assert actual_dict[key] == expected_value, f“键 {key} 的值不匹配。期望：{expected_value}，实际：{actual_dict[key]}” assert_dict_contains({‘status’: ‘success’, ‘code’: 0}, response.json())

策略三：使用专门的断言库，如pytest-assert-utils或deepdiff。对于极其复杂的深度比较，这些库是救星。

# 使用 deepdiff 进行深度比较，并生成可读的差异报告 from deepdiff import DeepDiff expected = {‘user’: {‘profile’: {‘name’: ‘张三’, ‘age’: 30}}} actual = {‘user’: {‘profile’: {‘name’: ‘张三’, ‘age’: 31, ‘city’: ‘北京’}}} diff = DeepDiff(expected, actual, ignore_order=True) assert not diff, f“数据结构存在差异：{diff}” # 如果存在差异，diff会是一个包含详细信息的字典，例如： # {‘values_changed’: {“root[‘user’][‘profile’][‘age’]”: {‘new_value’: 31, ‘old_value’: 30}}, ‘dictionary_item_added’: [“root[‘user’][‘profile’][‘city’]”]}

deepdiff能告诉你具体是值变了、项增加了还是删除了，在对比配置、复杂API响应时非常有用。

3.2 异常断言：验证代码是否按预期抛出错误

测试错误处理路径和边界条件，是保证代码健壮性的关键。pytest提供了非常优雅的异常断言方式。

import pytest def test_division_by_zero(): “”“测试除以零应抛出ZeroDivisionError”“” with pytest.raises(ZeroDivisionError): result = 1 / 0 def test_invalid_input(): “”“测试传入非法参数应抛出特定异常，并可检查异常信息”“” with pytest.raises(ValueError) as exc_info: # 捕获异常对象 int(‘invalid’) # 断言异常信息中包含特定文本 assert ‘invalid literal’ in str(exc_info.value) # 或者直接断言异常信息 # exc_info.value 就是捕获到的 ValueError 实例 assert exc_info.value.args[0] == “invalid literal for int() with base 10: ‘invalid’” def test_custom_exception(): “”“测试自定义异常”“” class InsufficientFundsError(Exception): pass def withdraw(amount, balance): if amount > balance: raise InsufficientFundsError(f“余额不足。当前余额：{balance}，尝试提取：{amount}”) return balance - amount with pytest.raises(InsufficientFundsError, match=r“余额不足.*余额：100.*提取：200”): withdraw(200, 100)

pytest.raises作为一个上下文管理器，其内部的代码块必须抛出指定的异常，测试才会通过。match参数可以使用正则表达式来匹配异常信息，这能确保抛出的异常不仅是正确的类型，信息内容也符合预期。exc_info对象可以让你在断言后继续检查异常的详细信息，非常强大。

实操心得：在测试异常时，一定要确保pytest.raises块内的代码确实会抛出异常。我见过有人写了with pytest.raises(...): some_code()，但some_code()其实永远不会抛异常，导致测试错误地通过了。这是一种静默的测试漏洞。对于重要的异常路径，可以故意先让测试失败，确认异常断言机制在工作，再修复代码让测试通过。

3.3 使用pytest内置的断言辅助函数

除了重写assert，pytest还提供了一些函数来应对特殊场景。

pytest.approx：前面提过，用于浮点数比较。它支持相对容差和绝对容差。

assert 99.9 == pytest.approx(100, rel=1e-2) # 相对容差1%，通过 assert 99.9 == pytest.approx(100, abs=0.1) # 绝对容差0.1，通过 assert 99.9 == pytest.approx(100, abs=0.01) # 绝对容差0.01，失败 # 对于容器内的浮点数也适用 assert [0.1 + 0.2, 1.0/3.0] == pytest.approx([0.3, 0.3333333])

pytest.fail：主动让测试失败，并给出原因。通常用在条件判断中，当测试不应该走到某个分支时。

def test_complex_condition(): result = some_complex_operation() if result.status == ‘error’: # 如果状态是error，我们期望error_code不为空 if not result.error_code: pytest.fail(f“当状态为error时，error_code不应为空。结果：{result}”) elif result.status == ‘success’: assert result.data is not None else: # 出现了未预期的状态 pytest.fail(f“未预期的状态值：{result.status}”)

这比写一堆复杂的assert和if-else逻辑更清晰，失败信息也更直接。

pytest.warns：用于断言代码会发出警告（Warning），类似于pytest.raises。

import warnings import pytest def test_deprecated_function(): with pytest.warns(DeprecationWarning, match=“此函数已弃用”): call_deprecated_function()

这在测试库的版本兼容性或迁移路径时很有用。

4. 断言在UI与API自动化测试中的实战模式

理论说再多，不如看实战。自动化测试最终要落地到具体场景。下面我们看看在Web UI测试（以Selenium/Playwright为例）和API测试中，如何高效、稳健地使用断言。

4.1 UI自动化测试中的断言策略

UI测试的断言核心是：等待元素达到预期状态后再断言。直接断言而不等待，是UI测试不稳定的最主要原因。

反模式：

# 不稳定的写法 element = driver.find_element(By.ID, “submit-btn”) assert element.is_enabled() # 页面可能还没加载完，元素可能尚未可点击

正解：使用显式等待（Explicit Wait）结合断言。

from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_login_button_state(): # 等待元素出现并可见 username_field = WebDriverWait(driver, 10).until( EC.visibility_of_element_located((By.ID, “username”)) ) username_field.send_keys(“testuser”) password_field = driver.find_element(By.ID, “password”) password_field.send_keys(“password”) # 关键：等待登录按钮变为可点击状态，然后断言 login_button = WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, “login-btn”)) ) # 此时再断言，是稳健的 assert login_button.is_enabled() assert login_button.text == “登录” login_button.click() # 断言登录后的页面跳转或元素出现 WebDriverWait(driver, 10).until( EC.url_contains(“/dashboard”) ) welcome_message = driver.find_element(By.CLASS_NAME, “welcome-msg”) assert “testuser” in welcome_message.text

在Playwright中，模式类似，但语法更简洁：

# Playwright 示例 def test_playwright_assert(page): page.goto(“/login”) page.fill(“#username”, “testuser”) page.fill(“#password”, “password”) # Playwright 自带自动等待，通常不需要额外的WebDriverWait login_button = page.locator(“#login-btn”) # 断言前，可以确保元素是可见、可用的 expect(login_button).to_be_enabled() # Playwright的断言库 expect(login_button).to_have_text(“登录”) login_button.click() # 断言导航 expect(page).to_have_url(“.*/dashboard”) expect(page.locator(“.welcome-msg”)).to_contain_text(“testuser”)

UI断言的最佳实践：

1. 断言文本内容时，使用部分匹配（in）而非完全匹配（==），避免因空格、换行或微小改动导致测试失败。

   assert “订单号：” in message_text # 好 assert message_text == “订单号：123456” # 脆弱（可能多一个空格就失败）

2. 断言元素状态（可见、可点击、被选中）前，务必等待。使用框架提供的等待机制，不要用time.sleep。
3. 对于列表或表格，断言数量或特定项的存在。

   rows = page.locator(“table tbody tr”) assert rows.count() == 5 # 断言是否存在包含特定文本的行 assert any(“待发货” in row.text_content() for row in rows.all())

4. 截图辅助断言：对于复杂的UI状态，有时断言失败信息不够直观。可以在断言失败时自动截图，这是定位UI问题的利器。可以通过pytest的钩子函数或try...except实现。

4.2 API接口自动化测试的断言要点

API测试的断言对象主要是HTTP响应：状态码、响应头、响应体（JSON/XML/文本）。

一个健壮的API测试断言示例：

import requests import pytest def test_create_user(): url = “/api/users” payload = {“name”: “李四”, “email”: “lisi@example.com”} headers = {“Authorization”: “Bearer token123”} response = requests.post(url, json=payload, headers=headers) # 1. 断言状态码（这是最基本的） assert response.status_code == 201, f“预期状态码201，实际为{response.status_code}，响应体：{response.text}” # 2. 断言响应头（如Content-Type, Location等） assert response.headers[“Content-Type”] == “application/json; charset=utf-8” # 创建资源后，Location头通常包含新资源的URL assert “Location” in response.headers new_user_url = response.headers[“Location”] assert “/api/users/” in new_user_url # 3. 解析并断言响应体 response_data = response.json() assert isinstance(response_data, dict) assert “id” in response_data assert isinstance(response_data[“id”], (int, str)) assert response_data[“name”] == payload[“name”] assert response_data[“email”] == payload[“email”] assert “created_at” in response_data # 4. 业务逻辑断言（例如，新创建的用户状态应为‘active’） assert response_data.get(“status”, “active”) == “active” # 5. （可选）使用返回的数据进行后续操作，验证数据一致性 # 例如，立刻调用GET接口，确认资源确实被创建 get_response = requests.get(new_user_url, headers=headers) assert get_response.status_code == 200 assert get_response.json()[“id”] == response_data[“id”]

API断言的核心技巧：

• 状态码是第一位：2xx代表成功，4xx代表客户端错误，5xx代表服务端错误。断言要精确，不要只断言response.ok。
• 处理动态数据：像id、created_at、token这种每次请求都会变的数据，不要断言其具体值，而是断言其存在性和类型。

  assert “token” in response.json() assert isinstance(response.json()[“token”], str) assert len(response.json()[“token”]) > 10

• 使用JSON Schema进行结构验证：对于大型、复杂的API响应，使用jsonschema库来验证响应结构是否符合预定模式，比写一堆assert语句更强大、更易维护。

  import jsonschema user_schema = { “type”: “object”, “required”: [“id”, “name”, “email”], “properties”: { “id”: {“type”: “integer”}, “name”: {“type”: “string”}, “email”: {“type”: “string”, “format”: “email”} } } jsonschema.validate(instance=response.json(), schema=user_schema)

• 断言性能（可选）：对于关键接口，可以加入响应时间的断言。

  import time start = time.time() response = requests.post(url, json=payload) end = time.time() assert (end - start) < 1.0 # 响应时间应小于1秒

5. 打造可维护的断言：模式、封装与最佳实践

当测试用例成百上千时，散落在各处的assert语句会成为维护的噩梦。重复的断言逻辑、不清晰的失败信息、对数据结构变化的脆弱性都会暴露出来。我们需要像组织生产代码一样来组织我们的断言。

5.1 封装自定义断言函数

将重复的、复杂的断言逻辑封装成函数，是提升代码复用性和可读性的第一步。

# conftest.py 或专门的断言模块中 def assert_valid_user(user_dict): “”“断言一个字典符合用户对象的基本结构”“” required_fields = [‘id’, ‘username’, ‘email’] for field in required_fields: assert field in user_dict, f“用户对象缺少必需字段：{field}” assert isinstance(user_dict[‘id’], int), f“id应为整数，实际是 {type(user_dict[‘id’])}” assert ‘@’ in user_dict[‘email’], f“邮箱格式无效：{user_dict[‘email’]}” assert len(user_dict[‘username’]) >= 3, “用户名至少3个字符” def assert_http_ok(response): “”“断言HTTP响应为2xx成功，并打印失败详情”“” assert 200 <= response.status_code < 300, \ f“请求失败！状态码：{response.status_code}，URL：{response.url}，响应体：{response.text}” def assert_list_not_empty(item_list, list_name=“列表”): “”“断言一个列表非空，并提供友好的错误信息”“” assert item_list, f“{list_name} 不应为空” assert isinstance(item_list, list), f“{list_name} 应为列表类型”

在测试中，使用这些封装好的断言，代码会干净很多：

def test_get_users(): response = client.get(‘/api/users’) assert_http_ok(response) users = response.json() assert isinstance(users, list) for user in users: assert_valid_user(user)

5.2 利用pytest的钩子增强断言失败报告

有时，默认的断言失败信息还不够。比如在UI测试中，我们希望在断言失败时自动截屏。这可以通过pytest的钩子函数pytest_assertrepr_compare或pytest_runtest_makereport来实现，但更简单的是在测试函数内部使用try...except。

一个更实用的模式是创建自定义的断言上下文管理器：

import pytest from contextlib import contextmanager from selenium import webdriver @contextmanager def assert_with_screenshot(driver, test_name): “”“一个上下文管理器，如果块内断言失败，则自动截图”“” try: yield except AssertionError as e: # 断言失败时，截图并附加到异常信息中 screenshot_path = f“./screenshots/assert_fail_{test_name}.png” driver.save_screenshot(screenshot_path) # 将原始异常信息和截图路径一起抛出 raise AssertionError(f“{e}\n断言失败截图已保存至：{screenshot_path}”) from e # 在测试中使用 def test_ui_functionality(): driver = webdriver.Chrome() driver.get(“...”) with assert_with_screenshot(driver, “test_ui_functionality”): element = driver.find_element(...) assert element.text == “预期文本” # ... 其他断言

这个技巧虽然简单，但在调试难以复现的UI问题时能救命。

5.3 断言与测试数据分离

不要让断言语句里塞满硬编码的测试数据。将测试数据（尤其是期望值）提取到外部文件或变量中。

# 不好的做法 def test_product(): product = get_product(123) assert product[“name”] == “智能手机旗舰版 X100” assert product[“price”] == 3999 assert product[“category”] == “电子产品” # 好的做法 EXPECTED_PRODUCT_123 = { “name”: “智能手机旗舰版 X100”, “price”: 3999, “category”: “电子产品” } def test_product(): product = get_product(123) for key, expected_value in EXPECTED_PRODUCT_123.items(): assert product.get(key) == expected_value, f“产品字段 {key} 不匹配”

或者使用pytest的参数化功能，将测试数据和断言逻辑分离得更彻底：

import pytest @pytest.mark.parametrize(“product_id, expected_name, expected_price”, [ (123, “智能手机旗舰版 X100”, 3999), (456, “无线蓝牙耳机”, 299), (789, “笔记本电脑”, 5999), ]) def test_products(product_id, expected_name, expected_price): product = get_product(product_id) assert product[“name”] == expected_name assert product[“price”] == expected_price

5.4 避免常见的断言陷阱

1. 过度断言（Assertion Roulette）：一个测试函数里塞了十几个assert，一旦失败，你很难快速知道是哪一个失败了。尽管pytest会指出失败的行号，但逻辑过于复杂仍不利于排查。建议：一个测试函数专注于验证一个逻辑点或一个场景。如果确实需要多个断言，确保它们高度相关，并使用清晰的失败信息。

2. 依赖测试执行顺序：测试断言依赖于前一个测试创建或修改的全局状态。这是自动化测试的大忌，会导致测试结果不可靠。必须保证每个测试都是独立的。使用setup_method/teardown_method或fixture来管理测试环境。

3. 断言不稳定的条件：例如断言页面加载的“精确时间”、断言网络请求的“绝对顺序”、断言包含当前时间戳的字段。解决方案：断言范围（如assert elapsed_time < 2.0），断言相对顺序，或者使用Mock/Stub来固定时间。

4. 忽略断言后的清理：特别是在集成测试中，一个断言失败后，测试函数可能提前退出，导致后续的清理代码（如删除测试数据、关闭连接）没有执行。使用try...finally或pytest的fixture来确保清理一定会执行。

   def test_with_resource(): resource = acquire_expensive_resource() try: # ... 你的测试和断言 assert resource.status == “ready” finally: # 无论断言成功还是失败，都会执行清理 release_resource(resource)

6. 调试与排查：当断言失败时该怎么办？

即使有了最好的实践，断言依然会失败。失败不可怕，可怕的是面对失败信息无从下手。下面是一个系统化的排查流程。

6.1 解读pytest的断言失败输出

首先，要会看pytest给出的信息。假设一个失败断言：

AssertionError: assert {‘name’: ‘Alice’, ‘age’: 25} == {‘name’: ‘Alice’, ‘age’: 26} Differing items: {‘age’: 25} != {‘age’: 26}

它清晰地告诉你，是age字段的值不匹配。如果结构更复杂，pytest会进行递归比较并输出差异树。养成习惯，首先仔细阅读pytest输出的第一行和最后几行，差异通常在那里。

6.2 使用pytest的-v和-s参数

• -v(verbose): 输出更详细的信息，包括每个测试的名字和状态。对于参数化测试，它会显示每组参数。
• -s: 关闭输出捕获，所有print语句和标准输出都会显示在控制台。这在调试时非常有用，你可以在测试中打印中间变量值。

  pytest test_file.py -v -s

6.3 在断言前打印调试信息

当复杂的断言失败时，在断言前打印出实际值，是最直接的调试方法。

def test_complex_data(): actual = some_complex_calculation() expected = load_expected_data() # 调试：先打印出来看看 print(f“Actual: {actual}”) print(f“Expected: {expected}”) # 或者使用pprint美化输出 import pprint pprint.pprint(actual, indent=2) assert actual == expected

运行测试时加上-s参数，你就能看到这些打印信息。

6.4 使用pdb进行交互式调试

对于特别棘手的失败，可以引入Python调试器pdb。

def test_buggy_function(): result = buggy_function() import pdb; pdb.set_trace() # 在这里设置断点 assert result == 42

运行测试时，程序会在pdb.set_trace()处暂停，进入交互式调试环境。你可以使用命令检查变量（p result）、单步执行（n）、进入函数（s）等。输入c继续运行，q退出。

6.5 常见断言失败模式速查表

断言是测试的灵魂，一个精心编写的断言不仅能发现bug，更能作为代码行为的活文档。从今天起，不要再把assert当成一个简单的检查开关，而是把它当作一个与代码对话、明确表达预期行为的工具。花时间优化你的断言，你的测试套件会回报你以稳定、可靠和高效的缺陷捕获能力。