测试

副标题 / 摘要 遗留代码的关键不是“重写”，而是“安全改动”。本文给出处理遗留系统的实用策略。 目标读者 维护老系统的工程师 需要降低改动风险的团队 负责技术债治理的负责人 背景 / 动机 遗留代码通常缺乏测试与文档，改动风险大。 安全改动的核心是“先建立保护网”。 核心概念 保护网：测试保证行为不变 最小安全改动：小步替换 分层改造：从外围开始逐步深入 实践指南 / 步骤 先补齐关键测试 隔离高风险模块 小步重构 + 频繁验证 避免一次性重写 建立可回滚机制 可运行示例 # 用单元测试保护关键行为 def calc(x): return x * 2 def test_calc(): assert calc(3) == 6 if __name__ == "__main__": test_calc() print("ok") 解释与原理 遗留系统的最大风险是“未知依赖”。 测试是最现实的安全网，能让你在改动时知道是否破坏行为。 常见问题与注意事项 一定要先写测试吗？ 是，否则无法安全改动。 重写是不是更快？ 通常不是，重写会遗漏隐性需求。 如何确定改造顺序？ 先改动频繁、影响大的模块。 最佳实践与建议 优先建立测试覆盖 用工具测量修改影响 逐步替换而非大爆炸式重写 小结 / 结论 遗留代码需要的是安全改动与渐进式重构。 测试是所有策略的核心。 参考与延伸阅读 Working Effectively with Legacy Code Refactoring (Martin Fowler) 元信息 阅读时长：7~9 分钟 标签：遗留代码、重构、测试 SEO 关键词：Legacy Code, 重构 元描述：遗留代码的安全改动策略与实践。 行动号召（CTA） 为你的遗留模块补一个最关键的测试，这是最划算的第一步。

副标题 / 摘要 测试不是开发的附属品，而是设计的反馈机制。本文说明“可测试性”如何影响模块边界、依赖方向与结构选择。 目标读者 负责设计模块结构的工程师 想提升测试覆盖与稳定性的开发者 需要制定工程规范的技术负责人 背景 / 动机 当代码难以测试时，往往意味着设计存在强耦合或隐藏依赖。 可测试性是一面镜子，能直接暴露设计问题。 核心概念 可测试性：代码是否能在隔离环境中被验证 依赖注入：把依赖显式传入，便于替换 边界分层：把 IO 与业务逻辑分离 实践指南 / 步骤 把 IO 与业务逻辑拆开 用函数参数或构造函数注入依赖 对外部系统做抽象接口 让核心逻辑保持纯粹、可复用 测试用例优先覆盖核心逻辑 可运行示例 class Repo: def get(self, user_id): return {"id": user_id, "name": "Alice"} class UserService: def __init__(self, repo): self.repo = repo def greeting(self, user_id): user = self.repo.get(user_id) return f"Hello, {user['name']}" class FakeRepo: def get(self, user_id): return {"id": user_id, "name": "Test"} if __name__ == "__main__": service = UserService(FakeRepo()) print(service.greeting(1)) 解释与原理 如果依赖都被隐藏在内部，测试无法替换外部依赖。 通过依赖注入与分层设计，测试可以只关注业务逻辑。 ...

副标题 / 摘要 TDD 的核心不是“测试优先”，而是“反馈优先”。本文解释为何先写测试能改善设计与质量。 目标读者 想尝试 TDD 的开发者 需要提升测试覆盖与设计质量的团队 负责工程规范的技术负责人 背景 / 动机 不写测试容易导致“改一点坏一片”。 TDD 通过先写测试迫使开发者明确需求与接口，从而降低返工成本。 核心概念 红-绿-重构：测试失败 -> 通过 -> 改进结构 最小实现：写刚好够通过测试的代码 反馈循环：快速验证假设 实践指南 / 步骤 先写失败的测试（定义行为） 写最小实现通过测试 重构代码保持测试通过 重复循环 可运行示例 # 测试 def test_sum(): assert add(1, 2) == 3 # 实现 def add(a, b): return a + b if __name__ == "__main__": test_sum() print("ok") 解释与原理 先写测试意味着先定义“期望行为”，再实现。 这会让接口更清晰、设计更简洁。 常见问题与注意事项 TDD 会不会降低效率？ 初期可能慢，但长期返工成本更低。 所有场景都适合 TDD 吗？ 不一定，探索性研发可先实验后补测试。 TDD 会导致过度设计吗？ 如果坚持“最小实现”，反而能控制复杂度。 最佳实践与建议 从核心逻辑开始做 TDD 保持测试小而快 把重构纳入流程 小结 / 结论 TDD 的价值是清晰需求、快速反馈与稳定演进。 先写测试不是教条，而是降低风险的方式。 ...

副标题 / 摘要 分布式系统的 bug 往往只在故障下出现。本文给出可落地的测试方法：故障注入、一致性校验与时钟模拟。 目标读者 做分布式系统的工程师 负责可靠性与稳定性的团队 想提高系统韧性的开发者 背景 / 动机 分布式系统没有单点真相，故障一旦发生就可能出现数据不一致与链路雪崩。 必须在测试阶段引入“故障场景”。 核心概念 故障注入：模拟节点宕机、网络分区 一致性验证：检查状态是否收敛 时钟偏移：时钟不同步导致逻辑错误 可观测性：日志、追踪、指标 实践指南 / 步骤 定义关键不变量（一致性约束） 故障注入（延迟、丢包、断连、宕机） 引入时间控制（时钟偏移/暂停） 验证收敛与恢复 回归与自动化 可运行示例 下面模拟“随机失败”的分布式写入： import random nodes = ["n1", "n2", "n3"] state = {n: 0 for n in nodes} def write(value): for n in nodes: if random.random() < 0.2: # 模拟失败 continue state[n] = value if __name__ == "__main__": write(10) print(state) 解释与原理 分布式系统的正确性取决于故障场景下的行为。 只有在测试里注入故障，才能提前发现问题。 常见问题与注意事项 只测正常路径够吗？ 不够，真正的 bug 都在异常路径。 故障注入会不会太贵？ 代价远低于线上事故。 ...

副标题 / 摘要 并发测试困难的根源在于非确定性与时序组合爆炸。本文解释为什么难、难在哪里，并给出工程实践建议。 目标读者 做并发/多线程开发的工程师 负责可靠性与测试的团队 想理解“偶发 bug”为何难测的人 背景 / 动机 并发 bug 往往“偶发、难复现、线上才出现”。 这是因为并发调度不可预测，导致测试难以覆盖所有时序组合。 核心概念 非确定性：调度顺序不可预测 时序组合爆炸：线程交错排列数量巨大 Heisenbug：调试本身改变时序 可复现性：复现条件苛刻 实践指南 / 步骤 把并发边界缩小（减少共享状态） 引入确定性调度或模拟器 使用竞态检测工具（如 TSAN） 加大压力与重复运行（概率提高） 记录关键事件与时间线 可运行示例 下面例子展示“偶发错误”很难稳定复现： import threading x = 0 def worker(): global x for _ in range(100000): x += 1 if __name__ == "__main__": threads = [threading.Thread(target=worker) for _ in range(2)] for t in threads: t.start() for t in threads: t.join() print(x) 在某些语言/环境下会出现不一致结果，这就是并发非确定性。 解释与原理 并发执行时，读-改-写不是原子操作。 调度顺序变化会导致结果不同，而这类问题很难通过少量测试覆盖。 ...