Python 测试框架选型：unittest vs pytest vs nose2

做自动化测试这么多年，我几乎把 Python 生态里的测试框架用了个遍。说实话，选框架这件事，有点像挑工具——没有的好坏，只有合不合适。今天我就把 unittest、pytest、nose2 这三个主流框架掰开揉碎讲清楚，帮你找到最适合自己项目的那一个。

一、框架概览：它们各自是什么来头？

先简单认识一下这三个框架的出身和定位。

框架	出身	定位	维护状态
unittest	Python 标准库，2001 年引入	内置测试框架，零依赖	稳定，随 Python 版本更新
pytest	社区驱动，2004 年诞生	现代化、插件化测试框架	活跃，社区生态丰富
nose2	nose 的继任者，2015 年发布	unittest 的增强版	维护中，但社区活跃度一般

嗯，这里要注意——unittest 是 Python 自带的，你装好 Python 就能用。pytest 需要 pip 安装，但它的流行度已经远超 unittest。nose2 嘛，我个人的建议是：除非你还在维护老项目，否则新项目不太推荐了。

二、核心特性对比：到底差在哪？

光看介绍不够，咱们直接上干货。我从几个关键维度做了对比，这些都是我在项目中踩过的坑。

1. 测试发现与执行

unittest 需要手动组织测试用例，或者用 TestLoader 来发现。pytest 则自动递归查找当前目录下所有 test_*.py 文件。我记得刚用 pytest 时，第一反应是「就这么简单？」——确实，它省去了很多样板代码。

# unittest 方式
import unittest

class TestMath(unittest.TestCase):
    def test_add(self):
        self.assertEqual(1 + 1, 2)

if __name__ == '__main__':
    unittest.main()

# pytest 方式
def test_add():
    assert 1 + 1 == 2

看到了吗？pytest 直接用 assert 关键字，不需要继承 TestCase，不需要写 self.assertEqual。说白了，就是更 Pythonic。

2. 夹具（Fixture）管理

夹具是测试框架的核心能力之一。unittest 用 setUp/tearDown，pytest 用 fixture 装饰器。我个人习惯用 pytest 的 fixture，因为它更灵活——可以指定作用域（function/class/module/session），还能自动注入。

# unittest 夹具
class TestDB(unittest.TestCase):
    def setUp(self):
        self.db = connect_to_database()
    
    def tearDown(self):
        self.db.close()

# pytest 夹具
import pytest

@pytest.fixture
def db():
    db = connect_to_database()
    yield db
    db.close()

def test_query(db):
    result = db.query("SELECT 1")
    assert result == 1

你想想看，pytest 的 yield 写法多优雅——setup 在 yield 前，teardown 在 yield 后。我曾经在项目中用 unittest 写了几百行 setUp/tearDown，后来重构为 pytest fixture，代码量直接砍半。

3. 参数化测试

参数化测试是 pytest 的杀手锏之一。unittest 需要自己写循环或者用 subTest，nose2 虽然支持但语法不够简洁。

# pytest 参数化
import pytest

@pytest.mark.parametrize("a,b,expected", [
    (1, 1, 2),
    (2, 3, 5),
    (10, -5, 5),
])
def test_add(a, b, expected):
    assert a + b == expected

这个特性在接口测试中特别有用。我做过一个支付系统的测试，需要验证几十种金额组合，用 parametrize 一行装饰器就搞定了，测试报告还会自动显示每个参数组合的执行结果。

4. 插件生态

pytest 的插件生态是它最大的护城河。目前有 1000+ 插件，覆盖了覆盖率、超时、重试、并行执行等几乎所有需求。unittest 几乎没有插件生态，nose2 的插件数量也远不及 pytest。

功能需求	pytest 插件	unittest 方案	nose2 方案
测试覆盖率	pytest-cov	coverage.py 手动集成	coverage.py 手动集成
失败重试	pytest-rerunfailures	无原生支持	无原生支持
并行执行	pytest-xdist	无原生支持	无原生支持
HTML 报告	pytest-html	无原生支持	无原生支持
Mock 对象	pytest-mock	unittest.mock（内置）	unittest.mock（内置）

三、选型建议：到底该用哪个？

说了这么多对比，最后给点实际建议。我根据不同的项目场景，总结了三套选型方案。

场景一：小型项目或快速原型

推荐：pytest

• 零样板代码，写测试就像写普通函数
• 自动发现测试，不需要手动注册
• assert 直接报错信息清晰，调试方便

场景二：大型企业项目或团队协作

推荐：pytest + 插件组合

• 用 pytest-xdist 做并行执行，缩短 CI 时间
• 用 pytest-cov 做覆盖率门禁
• 用 pytest-html 生成可视化报告
• 用 pytest-rerunfailures 处理不稳定用例

场景三：遗留项目或标准库依赖

推荐：unittest

• 零依赖，适合对第三方包有限制的环境
• 与 Python 标准库深度集成（如 mock、tempfile）
• 适合教学场景或对测试框架不熟悉的团队

四、框架选型决策流程图

下面这张图是我根据多年经验总结的选型决策流程，你可以直接拿来用。

五、我的最终建议

说了这么多，最后总结一下我的个人观点。

如果你问我新项目用什么，我会毫不犹豫地说：pytest。 它几乎在所有维度上都优于 unittest 和 nose2——更简洁的语法、更灵活的夹具、更强大的插件生态、更好的社区支持。我最近五年参与的所有项目，无一例外都选择了 pytest。

但如果你在维护一个已经用 unittest 写了上万用例的老项目，别急着迁移。先用 pytest 的兼容模式跑起来，然后逐步把新用例写成 pytest 风格，老用例保持不动。这样既享受了 pytest 的好处，又不会打断现有工作流。

至于 nose2，说实话，我只有在维护极少数老项目时才会用到。它的定位很尴尬——比 unittest 强一点，但远不如 pytest。新项目就别考虑了。