对外查询消息的单元测试：Python场景下正确测试方案问询

疑问1：用真实Wheel的测试是不是集成测试？ #

• 不属于集成测试。集成测试的核心目标是验证多个组件之间的交互逻辑是否符合预期，而这个测试的核心目标是验证Gear类对外公开的get_gear_inches方法的返回值是否符合业务预期，Wheel只是作为Gear的正常依赖传入，它的自身逻辑已经由Wheel的独立单元测试覆盖。
• Sandi Metz的核心测试原则是：测试对外公开的行为，不要测试内部实现细节。如果你Mock了wheel.get_diameter，本质就是把测试和Gear的内部实现绑定了——如果后续Gear的实现调整为直接访问wheel.diameter属性、或者调用wheel.calculate_diameter方法，哪怕get_gear_inches的返回值完全正确，测试也会失败，这就是典型的测试与实现耦合。

疑问2：如果依赖的查询方法有IO、耗时很长怎么办？ #

这种情况属于跨进程/跨边界的不稳定依赖，是可以用Mock的，但需要遵守两个前提：

1. Mock的返回值严格匹配依赖方法的公开契约，不能随意构造不符合真实逻辑的返回值
2. 要有单独的集成测试覆盖真实的查询逻辑，避免Mock约定和真实行为不一致

对应场景的正确测试方案 #

场景1：依赖是同进程内稳定、无IO、无副作用的轻量类（如示例中的Wheel） #

优先使用真实依赖测试，仅断言最终结果，完全不关注内部实现：

# 假设Wheel的构造参数为rim（轮辋直径）、tire（轮胎厚度），Gear的构造参数为chainring（牙盘齿数）、cog（飞轮齿数）
def test_get_gear_inches():
    test_wheel = Wheel(rim=26, tire=1.5)
    test_gear = Gear(chainring=40, cog=20, wheel=test_wheel)
    # 预期值 = 传动比 * 车轮直径 = (40/20) * (26 + 1.5*2) = 2 * 29 = 58
    assert test_gear.get_gear_inches() == 58

场景2：依赖的查询方法涉及外部IO、耗时高、不稳定 #

可以使用Mock，但要避免和实现绑定，不要添加不必要的调用断言：

from unittest.mock import Mock

def test_get_gear_inches_with_external_dependency():
    # 模拟依赖的查询方法返回符合契约的结果
    wheel_mock = Mock()
    wheel_mock.get_diameter.return_value = 29

    test_gear = Gear(chainring=40, cog=20, wheel=wheel_mock)
    assert test_gear.get_gear_inches() == 58

内容的提问来源于stack exchange，提问作者Kurt Bourbaki