python pytest
# 聊聊Python测试框架：为什么说pytest是当下最顺手的选择
写Python有一段时间后，你会发现测试这件事迟早要面对。不是那种“我要把代码质量提高到天上去”的崇高追求，而是当你改了一行代码，发现上个月还能运行的功能莫名其妙炸了。这时候你会想，要是能自动告诉我哪里出了问题该多好。
pytest就是干这个的。它是个测试框架，不管你写的代码是爬虫、Web服务还是数据分析脚本，都能用它来验证你的代码是否按预期工作。
它到底是什么
本质上就是个命令行工具。你写一堆以test_开头的函数，pytest就会自动找到它们，按顺序执行，然后告诉你有多少个通过了、多少个失败了、失败在哪个文件哪一行。
听起来和Python自带的unittest差不多？区别在于，pytest不需要你写类、不需要继承TestCase、不需要记一堆assertEqual、assertTrue这些方法。就普通的assert语句就行。比如你写了个加法函数：
defadd(a,b):returna+bdeftest_add():assertadd(2,3)==5assertadd(-1,1)==0就这么简单。pytest找到test_add函数，跑一遍，通过了就显示一个绿点，失败了就告诉你具体哪一行出了什么问题。
它能做什么
表面上看，就是运行测试。但真正让pytest有价值的是那些日常编码中会实际遇到的场景。
比如你有个函数要从数据库查用户余额。测试时你不想真的连数据库，不然每次跑测试都要准备测试数据、清理脏数据，想想就头疼。这时候pytest的fixture就派上用场了。你可以定义一个fixture，模拟数据库返回的数据，然后在测试函数里直接使用它：
@pytest.fixturedefmock_user_balance():return{"user_id":1,"balance":100.50}deftest_get_balance(mock_user_balance):assertmock_user_balance["balance"]==100.50fixture可以自动清理资源，比如测试完删除临时文件、关闭网络连接。你只需要在fixture里用yield代替return，yield后面的代码会在测试结束后执行。
再比如参数化测试。你有三个输入和对应的预期输出，不用写三个几乎一样的测试函数。pytest允许你在一个函数上标记多组参数：
@pytest.mark.parametrize("input_val, expected",[(1,2),(2,4),(3,6)])deftest_double(input_val,expected):assertinput_val*2==expectedpytest会生成三个独立的测试用例，哪个失败了会单独告诉你。
还有一个很少被提及但很实用的功能：断言失败时的信息非常详细。你写了assert a == b，如果不相等，pytest不但告诉你两边是什么值，还会显示它们具体差异在哪里。如果你比较两个长字符串，它会高亮显示第一个不同的字符位置；比较字典，它会告诉你哪些键值对不一致。这在调试的时候能省下大量时间。
怎么使用
安装就一句话：pip install pytest。
然后在项目根目录下创建测试文件。pytest默认会寻找当前目录及其子目录下所有以test_开头的文件，或者以_test.py结尾的文件。在这些文件里，它会寻找以test_开头的函数或者类（类名以Test开头且不含__init__方法）。
运行测试也很简单，终端里输入pytest，它会自动发现测试用例并执行。想只看失败的测试，加个-v参数；想停在第一个失败的地方，用-x；想运行特定文件，直接写pytest test_something.py。
写测试的时候，文件组织结构一般有两种方式。一种是把所有测试放在项目根目录的tests/文件夹里，和源代码分开。另一种是在每个模块旁边放一个test_文件。我个人更倾向于前者，尤其是在项目变大之后。因为测试文件通常会引入一些测试专用的依赖（比如mock库、测试数据），放在一起会让生产代码的导入路径变得混乱。
测试文件名尽量和被测模块对应。比如有个模块叫utils.py，测试文件就叫test_utils.py。这样找起来方便。
最佳实践
测试本身也是代码，需要维护。我见过最糟糕的情况是测试代码比生产代码还难懂，充斥着大量重复的setup代码和魔法数字。几个常见的做法：
fixture的作用域要合理。默认情况下每个测试函数执行前都会重新创建fixture。如果fixture里做了耗时的操作，比如启动浏览器、建立数据库连接，可以把作用域设为session或module，让多个测试共享同一个实例。不过要注意，共享状态意味着测试之间可能存在隐性依赖，这通常不是好事。有个折中的做法是把fixture设为class作用域，只在一个测试类里共享。
测试失败时给出的报错信息要足够明确。不要只写assert result，而要写assert result == expected。如果用了第三方库的响应对象，不要直接比较整个对象，而是比较关键字段。pytest的详细断言信息可以帮助你快速定位问题，但前提是你明确给出了预期值。
另一个技巧是使用conftest.py文件。在这个文件里定义的fixture、hooks和插件会作用于整个目录及其子目录。比如你有很多测试都需要一个数据库模拟环境，可以在tests/conftest.py里定义一次，所有测试文件都能共享。
mock的使用要克制。过度mock会导致测试和生产环境脱节。一个比较合理的原则是：mock外部依赖（网络、文件系统、数据库），但不mock自己的代码逻辑。如果你的函数里调用了另一个你写的函数，尽量使用真实的实现，除非那个函数的开销很大或者有副作用。否则测试通过了一堆mock，改天重构代码后mock的路径变了，测试全绿，生产炸了。
测试覆盖率不必追求100%。有些代码分支（比如异常处理里的日志记录）覆盖起来很麻烦，而且收益有限。重点覆盖核心业务逻辑和容易出错的边界条件，比如空列表、负数值、超大数据量。80%的覆盖率通常已经比大多数项目好得多了。
最后，测试应该是开发流程的一部分，不是事后补上的。你可以先写测试再写代码（TDD），也可以先写代码再补测试。重要的是每次提交代码前都跑一遍测试。可以在CI/CD里配置自动运行，也可以养成习惯在本地跑一遍。
和同类技术对比
Python生态里还有其他测试框架，最常用的有unittest和nose2。
unittest是Python标准库自带的，大家都很熟悉。它的特点是中规中矩，你需要写类、继承TestCase、用assertEqual系列方法。如果一个项目里所有人都用unittest，大家都很规矩，那也没什么问题。但它的组织方式比较死板，而且assert失败时的信息不够详细，经常需要你手动打印变量来调试。
nose2是nose的继任者，设计初衷是让测试变得简单。它和pytest类似，不需要写类，自动发现测试用例。但nose2的发展速度明显慢于pytest，社区活跃度也低很多。pytest有丰富的插件生态，比如测试覆盖率报告（pytest-cov）、用例并行执行（pytest-xdist）、失败重试（pytest-rerunfailures），这些都是noose2没有或者体验较差的。
如果非要说pytest的缺点，那就是fixture的学习曲线比unittest稍微陡一些。unittest的setUp/tearDown很直观，就是每个测试前准备、后清理。pytest的fixture可以嵌套、可以指定作用域、可以自动清理，功能更强大，但要理解它的运行机制确实需要一点时间。
另外pytest的插件虽然多，但有些插件的质量和维护情况参差不齐。在选择插件时，建议看看GitHub仓库的stars数量、最后更新时间、以及是否有已知的issue。
综合来看，对于新项目，pytest几乎是默认选择。对于已有的unittest项目，也不是非得迁移，但如果发现测试越来越难维护，可以考虑逐步替换。pytest可以直接运行unittest写法的测试用例，所以迁移的成本并不高。
说到底，测试框架只是工具。一个项目里测试代码好不好写、运行够不够快、失败信息够不够清晰，这些才是影响开发效率的关键。pytest在这些方面做得比较平衡，所以很多人愿意用它。