Why pytest ？

评价单元测试是否优秀，分支覆盖率是非常重要的指标，而覆盖率的决定因素除了开发自身的素质以外，足够低的用例构建成本也是必不可少。

对于 Python 应用，当项目逻辑复杂度较高时，单纯使用原生的 unittest 或者是 Django 提供的 TestCase 都会遇到一个恼人的问题：测试代码大部分工作在构建各种用例。幸好有 pytest 提供的 fixture 机制，可以较好的解决这个问题。

本文简单阐述个人的 pytest 使用实践，而关于 fixture 到底好在哪里或者具体使用方法，已经有比较多的文章做了更详细的介绍，我这里就不再赘述：

理想的单元测试

从理论来讲，对于一个测试项，我们应该只需关心测试内容的输入和输出（或异常），并且最好能够放到一起管理维护，更形象地说，应该是下面这种伪代码的感觉

1
2
3
4
5
6
7
8
9
10
(输入, 预期输出)
(输入, 预期输出)
(输入, 预期输出)
(输入, 预期异常)
def test_some_content(输入, 预期输出):
	if 正常:
		assert some_process(输入) == 预期输出
	else:
		with should_raise(预期异常):
			some_process(输入)

一个普通的 pytest 使用用例：

1
2
3
4
5
6
7
8
9
10
11
@pytest.fixture
def user():
    return User(name="Chris", hair_color=Color("brown"))

@pytest.fixture(autouse=True)
def set_user(client, user):
    client.set_user(user)

def test_set_user(client, user):
    # client.get_user() returns another User object
    assert client.get_user() == user

可以看出 pytest.fixture 固然能够足够强大，但是并不能完全解决问题：因为 fixture 在这里的用法是 静态 的，而对于我们理想的状态，用例中的输入输出，都应该是动态指定的。

一个简单的实践

所以，我们需要利用 fixture factory 来实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# fixture 依旧保留了复用性
@pytest.fixture
def make_fake_resp():
    def _make_fake_resp(input: str):
        def _wrapper(*args, **kwargs):
            return {"data": input}

        return _wrapper

    return _make_fake_resp

class TestUtils:
    @pytest.mark.parametrize(
        "input, expected",
        [
            # 正常情况
            ("abc", "xyz"),
						# 异常情况，当然也可以多拆分一个测试项
            ("abc", ValueError),
        ],
    )
    def test_some_content(self, input, expected, make_fake_resp):
        """测试某些内容"""

        with mock.patch('some-need-patching-refrences') as _patch:
						# 利用 fixture factory 动态生成测试用例
            _patch.side_effect = make_fake_resp(input)

            if type(expected) is type and issubclass(expected, Exception):
                with pytest.raises(expected):
										# 主体测试逻辑
                    call_test(input)
            else:
								# 主体测试逻辑
                assert call_test(input) == expected

这样一来，只要我在一开始构建好相关的工厂函数，添加更多的测试用例就只需在 parametrize 中不断添加即可，开发注意力成功从重复的工具构建转移到了真实用例。