在日常的 Python 开发中，我们写得最多的可能不是业务逻辑，而是各式各样的测试用例。常规的测试方法通常是“基于实例”的：我们设想几个正常的输入，再绞尽脑汁想几个边界情况（比如空列表、负数、极大值），然后写出对应的断言。
但问题在于，人类的想象力是有限的，Bug 往往藏在我们根本想不到的极端数据里。这时候，我们就需要转变思路，采用“基于属性的测试”（Property-Based Testing）。Python 生态中，这方面最强大的库就是 Hypothesis。
今天我们就来聊聊如何用 Hypothesis 彻底改变测试代码的编写方式。
什么是基于属性的测试？
不要被这个学术名词吓到。简单来说，常规测试是我们提供“具体数据”和“预期结果”；而基于属性的测试，是我们提供“数据类型的规则”和“程序必须满足的特性”，让测试框架自动生成成百上千种千奇百怪的数据去轰炸你的代码。
一旦发现代码报错，Hypothesis 还会做一件非常神奇的事情：缩小范围（Shrinking）。它会不断尝试精简导致错误的输入数据，最终把最简单、最直观的那个导致崩溃的反例扔到你面前。
Hypothesis 的工作流程
我们可以通过下面的流程图来直观理解 Hypothesis 是如何运作的：
graph TD A[定义输入数据的范围与策略] --> B[运行测试函数] B --> C[Hypothesis 自动生成随机输入流] C --> D{代码是否抛出异常或断言失败?} D -- 否 --> E[继续生成下一组数据] E --> C D -- 是 --> F[触发 Shrinking 缩减机制] F --> G[剔除冗余干扰因素] G --> H[输出导致崩溃的最小化核心数据集] E -. 达到最大测试次数 .-> I[测试通过]
核心概念与基础演示
要使用 Hypothesis，我们只需要掌握两个核心装饰器和模块：
@given：用于告诉测试函数，数据的来源。
strategies（通常缩写为 st）：用于定义如何生成这些数据。
先看一个非常基础的例子，假设我们要测试一个列表反转函数，它的“属性”应该是：把一个列表反转两次，结果一定等于原列表。
from hypothesis import givenimport hypothesis.strategies as stdef reverse_list(lst): return lst[::-1]# 测试：反转两次等于原列表@given(st.lists(st.integers()))def test_reverse_twice(lst): assert reverse_list(reverse_list(lst)) == lst# 测试：反转后的列表长度不变@given(st.lists(st.integers()))def test_reverse_length(lst): assert len(reverse_list(lst)) == len(lst)
在上面的代码中，st.lists(st.integers()) 就是一个策略，它告诉 Hypothesis：请给我生成各种各样的整数列表。Hypothesis 会自动尝试空列表、包含负数的列表、极长列表、包含重复数字的列表等。
实战演练：捕获隐藏的数学逻辑 Bug
上面的例子太简单了，我们来看一个更贴近实际数据处理的场景。假设我们在处理一批传感器信号数据，需要写一个数据归一化函数，将任意数值列表映射到 0 到 1 的范围内。
初版代码可能写成这样：
def normalize_signal(data): """将数据线性归一化到 0-1 范围""" max_val = max(data) min_val = min(data) return [(x - min_val) / (max_val - min_val) for x in data]
看着没毛病对吧？让我们用 Hypothesis 来测试一下。归一化函数的属性应该是：输出的结果列表，所有元素都应该在 0 到 1 之间，且输入输出长度一致。
from hypothesis import givenimport hypothesis.strategies as st@given(st.lists(st.floats(allow_nan=False, allow_infinity=False)))def test_normalize_signal_properties(data): result = normalize_signal(data) # 属性1：长度不变 assert len(result) == len(data) # 属性2：所有值都在 0 到 1 之间 for val in result: assert 0.0 <= val <= 1.0
当我们运行这个测试时，Hypothesis 会立刻打我们的脸。它会抛出错误，并给出最简化的失败用例：
Falsifying example: test_normalize_signal_properties(data=[])ValueError: max() arg is an empty sequence
原来我们忘记处理空列表了！修复它：
def normalize_signal(data): if not data: return [] max_val = max(data) min_val = min(data) return [(x - min_val) / (max_val - min_val) for x in data]
再次运行测试，Hypothesis 又抛出了错误：
Falsifying example: test_normalize_signal_properties(data=[0.0, 0.0])ZeroDivisionError: float division by zero
这次是因为，如果列表里的所有值都一样，max_val - min_val 就会等于 0，导致除零错误。这个测试用例 [0.0, 0.0] 就是 Hypothesis 经过缩减（Shrinking）后给出的最小反例。如果靠手写测试，我们很可能会漏掉这种所有元素完全相同的数据阵列。
最终修复版的代码：
def normalize_signal(data): if not data: return [] max_val = max(data) min_val = min(data) if max_val == min_val: # 如果所有值相同，统一归为 0.0 或保留原样，这里假设设为 0.0 return [0.0] * len(data) return [(x - min_val) / (max_val - min_val) for x in data]
经过这两轮修复，我们的代码健壮性得到了实质性的提升。这就是 Hypothesis 最迷人的地方：它像一个极其刁钻的代码审查员，专门寻找你的逻辑漏洞。
构建复杂的数据字典生成器
除了基础的列表和数字，实际开发中我们经常需要测试包含多种数据类型的复杂字典（比如模拟从后端 API 请求回来的 JSON 载荷）。Hypothesis 提供了 fixed_dictionaries 来精准控制字典结构。
from hypothesis import givenimport hypothesis.strategies as st# 定义一个模拟用户配置数据的生成策略user_config_strategy = st.fixed_dictionaries({ "username": st.text(min_size=3, max_size=20), "age": st.integers(min_value=0, max_value=120), "is_active": st.booleans(), # 甚至可以嵌套策略，比如生成包含多个浮点数的坐标列表 "coordinates": st.lists(st.floats(min_value=-180.0, max_value=180.0), min_size=2, max_size=2)})def process_user_data(config): # 模拟一个处理逻辑 if config["age"] >= 18 and config["is_active"]: return config["username"].upper() return "GUEST"@given(user_config_strategy)def test_process_user_data(config): result = process_user_data(config) # 断言属性 if config["age"] < 18 or not config["is_active"]: assert result == "GUEST" else: assert result.isupper() assert len(result) == len(config["username"])
结合开发框架的高级用法
如果你平时写很多异步代码（比如基于 Asyncio 的高并发任务），Hypothesis 也能完美适配。测试异步逻辑时，由于测试用例是由生成器驱动的，常规的 asyncio 运行方式会遇到障碍。这时候只要引入 pytest-asyncio 的支持即可：
import pytestfrom hypothesis import givenimport hypothesis.strategies as stimport asyncioasync def async_data_fetcher(query_id: int): # 模拟一个异步 I/O 操作 await asyncio.sleep(0.01) if query_id < 0: raise ValueError("ID cannot be negative") return f"Data_{query_id}"# 注意：需要同时使用 @pytest.mark.asyncio 和 @given@pytest.mark.asyncio@given(st.integers(min_value=0))async def test_async_data_fetcher_valid(query_id): result = await async_data_fetcher(query_id) assert result.startswith("Data_") assert str(query_id) in result@pytest.mark.asyncio@given(st.integers(max_value=-1))async def test_async_data_fetcher_invalid(query_id): with pytest.raises(ValueError): await async_data_fetcher(query_id)
总结
引入 Hypothesis 后，你编写测试的思维习惯会发生彻底的改变。你不再需要去猜测“代码在什么情况下会崩溃”，而是去思考“无论输入什么，代码的哪些本质规律是永远不变的”。这种思维方式不仅能找出深藏的 Bug，还能逼迫你在写业务代码之前，更清晰地界定函数的设计边界。
编辑：余文彬
审校：余雨馨
10个月宝宝每天需要喝多少奶粉？
