一个自学Python的人，把计算器代码改了3遍。第一版能跑，第三版能测。中间差的不是技术，是对"可测试性"的理解。
这故事来自一位正在学QA自动化（质量保证自动化测试）的开发者。他的GitHub仓库记录了完整演进：从200行混乱脚本，到能跑100个测试用例的类结构，只改了3个核心决策。
第一版：能跑，但测不了
代码长这样——从上到下流水账，input()和计算逻辑焊死在一起。用户不敲键盘，程序就卡住。
作者的原话：「You can't test code that demands user input just to run.」
这是大多数自学者的起点。功能对了，但测试覆盖率是0%。想验证加法对不对？只能手动跑一遍。想测除零错误？先自己输个0进去。
问题根源：输入和逻辑住在一个房间里，测试工具进不去。
第二版：把逻辑"拔"出来
改动很小。把加法、减法拆成独立函数，input()留在主流程。
效果立竿见影。测试可以这样写：def test_add(): assert add(2, 3) == 5。没有弹窗，没有等待，毫秒级反馈。
作者形容这种感觉像「superpower」。但更重要的是他意识到的规律：Functions are the foundation of testable code. If you can't call it in isolation, you can't test it properly.
函数隔离 = 可测试性的地基。这个认知直接影响了第三版的架构选择。
第三版：类结构不是为了"高级"
最终版本用类（Class，面向对象编程中的核心结构）包裹计算逻辑，并加入错误处理。
关键转折在divide方法。加了一行if b == 0: raise ZeroDivisionError，测试场景从"正常输入"扩展到"异常输入"。
测试代码变成：with pytest.raises(ZeroDivisionError): calc.divide(10, 0)。不仅能测对，还能测错。
作者的总结很直接：「OOP isn't just about organisation — it's about making your code extensible and testable at scale.」
类结构的价值不是代码看起来更"专业"，而是给测试提供了钩子（Hook，测试框架接入代码的接口）。每个方法都是独立的测试单元，异常路径和边界条件能被系统化覆盖。
给QA学习者的启示
这位作者正在学Pytest和Playwright（两款主流自动化测试工具）。他的实战经验是：真实自动化工作中，你永远不会在一个地方测试所有东西。
测试逻辑、业务逻辑、页面交互必须分层。如果代码结构没提前隔离，后期补测试的成本是指数级增长。
他的3版重构，本质上是在模拟工业级QA的工作流程——先让代码可被测试，再写测试。
GitHub仓库地址在文章开头。如果你也在学自动化测试，可以对比三个版本的差异。一个值得想的问题：你现在的代码，第几版水平？
热门跟贴