可测试代码的核心是确定性、独立性与易隔离性：函数输入相同则输出固定，不依赖外部状态；业务逻辑与数据库、网络等副作用操作分离；通过依赖注入传入“能干活的对象”，避免硬编码；函数无副作用、纯返回结果；合理拆分粒度，单一职责。
写出可测试的代码，核心是让函数或类的行为**确定、独立、易隔离**——不依赖外部状态（如文件、网络、全局变量），输入相同则输出固定，副作用可控。
把业务逻辑和外部交互分开
数据库操作、HTTP 请求、读写文件这些容易出错且慢的操作，应该从核心逻辑中抽离出来。用参数传入“能干活的对象”，而不是在函数里直接调用 requests.get 或 open()。
- 比如处理用户数据的函数，不要自己连数据库查用户，而是接收一个
user_repo对象，由它提供get_user(id)方法 - 测试时就传个模拟对象（mock），返回预设的用户字典，逻辑层完全不受数据库影响
函数尽量无副作用、只返回结果
避免修改传入的列表、字典，或改动全局配置。纯函数更容易断言、复现和并行测试。
- ❌ 不推荐：
def add_item(items, new_item): items.append(new_item)—— 修改原列表，测试得先备份 - ✅ 推荐：
def add_item(items, new_item): return items + [new_item]—— 输入不变，输出明确，一行就能测
用依赖注入替代硬编码依赖
类内部不要直接实例化下游服务，而是通过构造函数或方法参数接收。这样单元测试时可以轻松替换为测试替身（stub/mock/fake）。
- 例如发邮件的服务类，别在订单类里写
self.emailer = EmailService() - 改成
def __init__(self, emailer: EmailerProtocol)，测试时传个DummyEmailer记录是否被调用即可
合理划分函数粒度，避免过长或过重
一个函数只做一件事，且这件事足够小。太大的函数难以覆盖所有分支，也难定位失败原因。
- 比如“提交订单”函数，拆成
validate_order()、reserve_inventory()、charge_payment()等独立单元 - 每个子函数可单独测试边界条件：空地址、库存不足、支付超时等
