第四章 断言框架入门：unittest断言方法、pytest断言风格、JUnit断言

好，咱们今天聊聊断言框架。说实话，很多新手写测试时，最纠结的就是「我该用什么方式去验证结果」。你想想看，断言就是测试的「法官」——它说了算。我这些年带团队，发现不少人把断言写成了「玄学」，要么太啰嗦，要么根本测不到点上。

这一章，咱们把三个主流框架的断言掰开揉碎。unittest、pytest、JUnit，它们各有脾气。我会告诉你每个框架的「正确打开方式」，以及我踩过的坑。

4.1 unittest断言：老牌框架的「规矩」

unittest是Python自带的测试框架。它的断言方法，说白了就是一套「官方话术」。每个断言都有固定的方法名，你得像填表格一样去调用。

我个人习惯把unittest断言分成三类：

• 值断言：判断两个值是否相等、是否为真、是否为None
• 集合断言：判断列表、字典、元组等是否包含、是否相等
• 异常断言：判断某段代码是否抛出了预期的异常

来，看个例子：

import unittest

class TestMathOperations(unittest.TestCase):
    
    def test_addition(self):
        # 值断言：判断相等
        self.assertEqual(1 + 1, 2)
        # 值断言：判断为真
        self.assertTrue(3 > 2)
        # 值断言：判断为None
        self.assertIsNone(None)
    
    def test_list_contains(self):
        my_list = [1, 2, 3, 4]
        # 集合断言：判断元素在列表中
        self.assertIn(3, my_list)
        # 集合断言：判断列表相等
        self.assertListEqual(my_list, [1, 2, 3, 4])
    
    def test_raises_exception(self):
        # 异常断言：判断是否抛出ZeroDivisionError
        with self.assertRaises(ZeroDivisionError):
            1 / 0

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

嗯，这里要注意。unittest的断言方法名特别多，我刚开始用的时候也记不住。后来我总结了一个小技巧：只记最常用的5个，其他的查文档就行。

方法名	用途	我常用的场景
assertEqual(a, b)	判断 a == b	验证函数返回值
assertTrue(x)	判断 x 为 True	验证条件成立
assertIn(a, b)	判断 a 在 b 中	验证列表包含元素
assertRaises(Exc, fun)	判断抛出异常	验证错误处理
assertAlmostEqual(a, b)	判断浮点数近似相等	验证计算精度

4.2 pytest断言：Pythonic的「自由」

pytest的断言风格，跟unittest完全不一样。它用的是Python原生的 assert 关键字。说白了，你怎么写Python代码，就怎么写断言。

为什么会这样？因为pytest的设计哲学是「少即是多」。它觉得你不需要记住几十个方法名，一个 assert 就够了。我个人非常喜欢这种风格，写起来特别顺手。

# test_sample.py
def test_addition():
    assert 1 + 1 == 2

def test_list_contains():
    my_list = [1, 2, 3, 4]
    assert 3 in my_list

def test_raises_exception():
    import pytest
    with pytest.raises(ZeroDivisionError):
        1 / 0

def test_approximate():
    # pytest支持近似比较
    assert 0.1 + 0.2 == pytest.approx(0.3)

你看，pytest的断言就是普通的Python表达式。它唯一特殊的地方是 pytest.raises 和 pytest.approx 这两个辅助工具。

pytest还有一个杀手锏——断言失败时的信息非常详细。它会告诉你左边是什么值，右边是什么值，甚至能帮你分析出为什么失败。这一点，unittest就做不到。

4.3 JUnit断言：Java世界的「标准」

JUnit是Java生态里最流行的测试框架。它的断言风格，跟unittest有点像，也是通过静态方法调用来实现。

JUnit 4和JUnit 5的断言方法略有不同。JUnit 5引入了 Assertions 类，提供了更丰富的断言方法。我个人建议直接学JUnit 5，因为它是未来的方向。

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

public class MathTest {
    
    @Test
    void testAddition() {
        assertEquals(2, 1 + 1, "1 + 1 应该等于 2");
    }
    
    @Test
    void testListContains() {
        List<Integer> list = Arrays.asList(1, 2, 3, 4);
        assertTrue(list.contains(3));
    }
    
    @Test
    void testException() {
        assertThrows(ArithmeticException.class, () -> {
            int result = 1 / 0;
        });
    }
    
    @Test
    void testGrouped() {
        // JUnit 5 支持分组断言
        assertAll("分组验证",
            () -> assertEquals(2, 1 + 1),
            () -> assertTrue(3 > 2),
            () -> assertNotNull("hello")
        );
    }
}

JUnit 5的 assertAll 方法特别实用。它会把分组里的所有断言都执行一遍，然后一次性报告所有失败。我记得有一次重构代码，用 assertAll 一次性发现了5个回归问题，省了我不少时间。

4.4 知识体系总览

下面这张图，是我梳理的断言框架核心逻辑。你可以看到，三个框架虽然写法不同，但底层逻辑是相通的：都是「输入 → 执行 → 验证」这个流程。

你想想看，不管用哪个框架，核心都是这三类断言。值断言验证「对不对」，集合断言验证「全不全」，异常断言验证「稳不稳」。掌握了这个逻辑，换框架就是换层皮的事。

好了，这一章的内容就到这里。记住：断言不是写给别人看的，是写给未来的自己看的。写得好，能省你无数调试时间。写得不好，嗯……你懂的。