3. 技术选型：Python 测试框架对比

聊到 Python 测试框架，很多人第一反应就是 unittest。嗯，毕竟它是标准库里的，开箱即用。但我个人不建议你在 SDK 兼容测试这种场景里直接用 unittest。

为什么？你想想看，SDK 兼容测试要测什么？不同操作系统、不同语言版本、不同依赖组合。测试用例少说几百条，多则上千。这时候框架的灵活性、扩展性、可读性就变得非常重要了。

我最早接触自动化测试时，也用 unittest 写过几个项目。后来换到 pytest，就再也回不去了。今天我就拿三个主流框架——unittest、nose、pytest——做个对比，说说我为什么坚定地选择 pytest。

3.1 三大框架速览

先看一张对比表。我习惯把关键差异列出来，这样决策时一目了然。

特性 unittest nose pytest
设计哲学 Java 式 xUnit 风格 简化 unittest 函数式 + 插件化
编写风格 必须继承 TestCase 类 同 unittest，但支持函数 纯函数 + 类均可
Fixture 机制 setUp / tearDown 同上，增加生成器支持 fixture 依赖注入
插件生态 官方有限 已停止维护 800+ 插件
断言方式 assertEqual、assertTrue 等 同上 原生 assert + 友好提示
参数化测试 subTest 复杂 第三方插件 @pytest.mark.parametrize
并行执行 不支持 不支持 pytest-xdist

3.2 unittest：熟悉但笨重

unittest 最让人头疼的是什么？样板代码。每个测试类都得继承 unittest.TestCase，每个方法都得用 self.assertEqual 那一套。我在项目中遇到过一次，一个 SDK 的兼容测试用例写了 300 行，其中 80 行是 setup 和断言方法调用，真正有用的逻辑反而被淹没了。

另一个问题是 fixture 的作用域。unittest 只有类级别和方法级别的 setUp/tearDown。如果你想要模块级或 session 级的 fixture，就得自己手动写代码处理。说白了，它不优雅。

unittest 的痛点

  • 强制继承，测试代码与框架耦合度高
  • fixture 作用域有限，复用困难
  • 断言方式冗长，调试信息不直观
  • 缺乏参数化和并行能力

3.3 nose：曾经的选择，已停止维护

nose 是 unittest 的一个简化版本，早期很多人用它。我记得 2015 年左右，我在一个老项目里还在用 nose。但它有个致命问题——项目已经停止维护了。Python 3.10 之后的版本，nose 基本跑不动。

我不建议任何新项目考虑 nose。哪怕它用起来比 unittest 顺手一点，但一个不再更新的框架，放在兼容测试这种长期维护的体系里，就是个定时炸弹。

注意：nose 在 2015 年后就没有正式发布了。Python 3.10+ 环境中，很多插件和内部接口已经不兼容。

3.4 pytest：我选择它的理由

好了，重点来了。说说我为什么坚定地站在 pytest 这边。

理由一：极简的编写方式

pytest 允许你用普通函数写测试，不需要继承，不需要类。来看一个最简单的例子：

# test_sdk_version.py
def test_version():
    assert get_sdk_version() == "2.1.0"

两行代码就是一个测试用例。如果这个测试失败，pytest 会输出详细的信息——不仅告诉你哪个 assert 失败了，还会显示两边的实际值。这一点在调试兼容性差异时特别有用。

理由二：强大的 fixture 机制

fixture 是 pytest 的核心特性之一。你可以把测试依赖（比如初始化 SDK 客户端、准备测试数据、创建临时文件）声明为 fixture，然后按需注入：

import pytest

@pytest.fixture
def sdk_client():
    # 这里初始化 SDK 客户端
    client = SDKClient(="test_key", base_url="https://sandbox.example.com")
    yield client
    # 测试结束后清理资源
    client.close()

def test_user_info(sdk_client):
    info = sdk_client.get_user("123")
    assert info["name"] == "Alice"

fixture 可以设置不同的作用域：函数级、类级、模块级、session 级。我在做跨版本兼容测试时，经常把 SDK 客户端初始化设成 session 级，这样整个测试会话只实例化一次，大幅缩短总执行时间。

理由三：丰富的插件生态

pytest 的插件系统非常成熟。以下是我在 SDK 兼容测试中必装的几个插件：

插件 用途
pytest-xdist 分布式并行执行测试
pytest-cov 计算测试覆盖率
pytest-ordering 控制测试用例执行顺序
pytest-html 生成漂亮的 HTML 报告
pytest-timeout 设置单条测试的超时时间

理由四：参数化测试

SDK 兼容测试经常需要覆盖大量输入组合。pytest 的 @pytest.mark.parametrize 让我用一份代码测试所有组合：

import pytest

# 测试 SDK 对不同操作系统的兼容性
operating_systems = ["windows", "linux", "macos"]
sdk_versions = ["2.0.0", "2.1.0", "2.2.0"]

@pytest.mark.parametrize("os", operating_systems)
@pytest.mark.parametrize("version", sdk_versions)
def test_compatibility(os, version):
    env = setup_environment(os, version)
    result = env.run_sdk()
    assert result.success

这段代码会自动生成 3×3=9 个测试用例。如果某个组合失败了，pytest 会精确报告是哪个参数组合出了问题。

小建议：参数化测试写多了，你会发现它比 for 循环干净得多。每个参数组合都是一个独立的测试结点，失败时互不影响。

3.5 为什么在 SDK 兼容测试中特别适合 pytest

SDK 兼容测试有一个典型场景——矩阵测试。不同语言版本、不同操作系统、不同依赖版本，排列组合起来经常是数十甚至上百种环境。pytest 的参数化 + fixture + 插件生态，恰好完美覆盖了这个需求。

我曾经在一个项目中用 unittest 写矩阵测试，每个环境组合都需要单独定义一个测试方法，代码量暴增。换到 pytest 后，用 @pytest.mark.parametrize 配合一个 fixture 管理环境初始化，整个测试模块缩减了 60% 的代码行数。

另外，pytest 的 assert 失败信息非常详细。你在对比不同 SDK 版本的行为差异时，一眼就能看出哪个字段、哪个值、哪个预期和实际不一致。unittest 的 assertEqual 只会告诉你"不相等"，但 pytest 会告诉你左边的值和右边的值分别是什么。

3.6 选型决策框架

最后，我把选型决策的核心逻辑画成了一张图。你可以用它快速判断自己的项目该选哪个框架。

Python 测试框架选型决策图 项目需求 兼容性测试场景？ 简单测试 (unittest) pytest pytest-xdist 并行执行 pytest-cov 覆盖率 pytest-html 报告 建议：新项目首选 pytest；老旧项目可迁移，也可保留 unittest

从图上可以很清楚地看到：如果你的项目规模小、团队习惯 unittest、且没有复杂的兼容性测试需求，那么 unittest 也凑合能用。但只要涉及到多环境、多版本、多参数的兼容性验证，pytest 就是不二之选。

3.7 小结

选框架这步走对了，后面写测试代码会顺手很多。我这几年经手的 SDK 兼容测试项目，全部统一用 pytest。简单归纳三点理由：

  • fixture 机制让环境管理变得优雅
  • 参数化让矩阵测试变得简单
  • 插件生态让并行、覆盖率、报告等需求开箱即用
← 上一章 📖 返回目录 下一章 →