单元测试入门：代码质量的第一道防线

可视化演示

展示单元测试的AAA用例设计模式、Mock依赖隔离技巧和代码覆盖率分析，通过模式切换理解测试工程的核心实践。

测试基本概念

老陈有个雷打不动的规矩：每根木头进屋前先敲一敲。这不是仪式感，是三十年的经验——木头看着光滑，敲着发“空”就得警惕，内核裂了的地方，手摸不出来，但声音骗不了人。软件世界也一样：函数看起来没问题，一传入奇怪的参数就悄悄返回了错误结果。测试，就是那把能“敲出内伤”的小锤。

软件里的“敲木头”叫做单元测试。它把程序里一个最小的代码单元（通常是一个函数或一个类的方法）单独拎出来，喂给它固定的输入，再检查它吐出的输出是否符合预期。它不弹界面、不连数据库、不请求网络，只关心这一段代码自己站不站得住。在 AI 工程里，数据清洗、特征计算、模型推理封装这些函数，每个都值得先“敲一敲”再上生产。

测试界的经典坐标系叫“测试金字塔”，它把测试分成三层：最底层是海量单元测试，中间是少量集成测试，顶层是极少数端到端测试。单元测试跑得最快、定位最准、成本最低，所以撑起金字塔的地基。同时要分清“测试”与“调试”：测试负责发现问题，调试负责定位并修复问题——一个是体检，一个是手术。

老陈不敲每根木头的每一个毛孔，但他保证每根木头都敲过。单元测试就是那把不厌其烦的小锤——用最便宜的动作，挡住最贵的灾难。

测试用例设计

老陈检查木材要分种类：松木看虫眼，橡木看裂纹，湿料看变形。他不可能把每块木头翻来覆去查一百遍，但分好类、每类抽一块代表性的检查，就能覆盖绝大多数问题。这种“分类抽查”的智慧，正是测试用例设计的精髓。

所谓测试用例设计，就是把无穷无尽的输入空间压缩成有限几个必测点。你不可能把全世界所有数字都喂给一个函数，但你可以把输入“分门别类”，每一类挑一个代表来测。经典的三个工具箱是：等价类划分、边界值分析、因果图方法。等价类划分把输入按行为分成“有效等价类”（程序该受理的）和“无效等价类”（程序该拒绝的）；边界值分析专门盯着取值范围的两端；因果图则处理多个条件组合出不同结果的复杂场景，避免重复冗余的用例。

设计用例时新手最容易犯的错是只测“正常情况”：传个 100 进去，返回 90，绿灯一亮就收工。可程序真正翻车的地方，全在那些“合法之外”的输入上。无效等价类测的是程序的“脾气”——收到不合理的输入时，是优雅地抛出异常，还是直接崩给你看？

老陈分木料、分情况、分类抽查，你的测试也照这个思路来：先分组，再抽代表，最后把合法与非法两条路都走一遍。分类清晰了，一敲一个准。

Mock技巧

老陈要单独验收一根梁的卯榫是否合格，不会干等隔壁的柱子装好了再来试——他手里有一套标准卯口样板，随时拿起来一卡，合不合格当场见分晓。这套样板，就是测试世界里的 Mock。

被测函数往往有一堆“邻居”：要连数据库、要调第三方支付接口、要读取系统当前时间。这些邻居要么太慢、要么太贵、要么行为不可控。Mock 就是一个伪造的邻居，它的接口长得和真邻居一模一样，但行为由你说了算——你想让它返回 500 就返回 500，想让它超时就超时。这样一来，被测函数被装进“真空实验室”，跑得快、结果稳。

Mock 的三大用途：第一，隔离外部依赖，测试不连数据库、不发网络请求，秒级跑完；第二，模拟稀缺场景，比如让支付接口故意报错，验证你的降级逻辑；第三，行为验证，除了看返回值，还可以断言“某个方法被调用了几次、传了什么参数”。但要记住，Mock 验证的是“形似”而非“神似”——它必须和真实依赖的接口契约保持一致，否则就是自欺欺人。

标准卯口样板让老陈在工位上就能验梁，Mock 让开发者不启动整个系统就能验函数。先把零件验明白，再谈整栋楼的装配。

边界条件覆盖

房子最容易出问题的地方永远是边角：墙角的雨水渗漏、窗框的接缝开裂、梁头的榫口松动。老陈验收的标准动作是“挑两头”——每根梁两端的榫头各敲三下，中间反而不那么费心。代码里的 bug 也偏爱边界：循环恰好取到最后一个元素、金额刚好等于阈值、字符串长度刚好是最大值。

边界条件覆盖，就是专门在取值范围的两端做文章。经典陷阱包括：空值处理，用户没传参数怎么办；极值边界，金额取到最大值、数组取到超大容量；异常输入，负数、溢出、格式错误。这类 bug 的共同特点是“差一点”——判断条件少写了等号，循环多走了一轮，也就是传说中的 off-by-one 错误。

对付边界问题有一把标准尺子：对任何合法取值区间，至少要测六个点。比如打折接口规定价格区间是 0 到 10000，那 -1、0、1、9999、10000、10001 这六个值一个都不能少，每一个都有它必须被“正确对待”的理由。

老陈敲梁头，你看数组的两端和阈值的两侧。边界守住了，中间大概率塌不了——这是代码世界里最划算的投资。

覆盖率度量

老陈有一本验收账本，每验完一块木头就画一个勾。月底一翻：100 根木头只验了 60 根，剩 40 根是“没验过”的，他心里立刻有数——还有四成风险没排查。账本上的百分比，对应到代码世界就是覆盖率。

覆盖率，通俗讲就是“测试运行时，到底有多少代码被执行过”。它是一份体检报告，告诉你身体哪些部位检查过了、哪些部位还是盲区。最常见的两个指标：行覆盖率看“每行代码有没有被执行”，分支覆盖率看“if 和 else 这两条岔路是不是都走过”。工具方面，Python 用 pytest-cov，Java 用 JaCoCo，前端用 Istanbul。

但覆盖率有个大坑：它只统计“执行过”，不统计“验证对”。一行代码被跑了一百遍，如果断言永远只检查返回值大于零，那它依然是裸奔。行业里常设 80% 的门槛，但这个数字的意义是“划定盲区警戒线”，而不是“通关免检章”。看到 100% 覆盖率，正确的反应不是欢呼，而是追问：每条分支都真正验证了正确的行为吗？

账本上的勾是老陈信心的来源，覆盖率是你的“测试账本”。但记住，账本只记录“验过没有”，不记录“验得多认真”。

测试工程化

一个人盖房怎么干都行，但老陈的工程队有二十号人，各行其事必然出乱子。于是工地立下规矩：每天早会分工、材料入库登记、每周联合检查、谁负责的部件出问题追责到人。流程，让手艺变成了工程。测试也一样，从“我随手写了个脚本”到“团队规范地测”，中间隔着一整套工程化体系。

测试工程化的核心三件套：测试框架、持续集成、测试规范。框架是统一的“语言”，Python 用 pytest，Java 用 JUnit，前端用 Jest，大家写出来的测试风格一致、能自动发现、能汇总报告。持续集成（CI）是门禁——每次 git push 都自动拉取代码、跑全部测试，红灯亮了就阻断合并，把问题挡在合入主分支之前。规范则是约定俗成的章法：测试文件放哪、怎么命名、测试数据怎么管理。

工程化还有一个经典节奏叫 Red-Green-Refactor：先写一个必然失败的测试（红灯），再写最简代码让它通过（绿灯），然后放心重构（保持全绿）。这个循环把“写代码”和“写测试”焊在了一起，让测试不再是事后补作业，而是前进的导航仪。

老陈的工地规矩，对应到你仓库里的 CI 流水线、测试目录和红绿循环。把个人手艺沉淀成团队流程，质量才不会随人员流动而流失。

测试可维护性

老陈的账本越记越厚，如果只有他自己看得懂，他一休假，新来的工匠准抓瞎。所以他从第一页就定下统一格式：日期、木材编号、问题描述、处理结果。每个字都是写给未来的同行看的。测试代码是同样的道理——它是写给明天看的，而“明天”可能是你自己，也可能是接手你代码的陌生人。

测试代码也是代码，它会被阅读、被修改、被维护。写得烂的测试比不写更痛苦：天天随机报错，你天天“修测试”，耗尽耐心后干脆删掉，防线就此崩塌。三条可维护性准则能救你于水火：命名即文档，test_订单金额超过100_自动减20 失败时，一眼就知道业务逻辑哪一环坏了；断言要精准，一个测试只验证一个行为，用 assertEqual 而不是含糊的 assertTrue；避免脆弱断言，不依赖实现细节、不依赖执行顺序、不用 sleep 等时间，把“时好时坏”的脆弱测试消灭在萌芽里。

测试重构也遵循 Red-Green-Refactor：先有绿灯保护，再大胆调整测试代码的结构。删除重复的夹具代码、提炼公共的构造方法、把过长的测试拆成多个意图单一的小测试——每一步重构都以“仍然全绿”作为安全网的反馈。

老陈的账本是写给后来人的，你的测试是写给明天自己的。一份清晰、稳定、易读的测试，才是能陪你走完整个项目周期的老伙计。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""单元测试入门演示: 会员折扣计算器的测试设计"""import unittestfrom unittest.mock import Mock  def calc_discount(price, level):    """根据会员等级计算折后价, 展示等价类与边界值思想"""    if price is None or price < 0:        raise ValueError("price 不能为空或负数")    if level not in ("normal", "vip", "svip"):        raise ValueError("未知会员等级")    rate = {"normal": 1.0, "vip": 0.9, "svip": 0.8}[level]    return round(price * rate, 2)  class TestCalcDiscount(unittest.TestCase):    """等价类: normal/vip/svip 三类各取一例"""     def test_normal_keeps_price(self):        self.assertEqual(calc_discount(100, "normal"), 100.0)     def test_vip_gives_ten_percent_off(self):        self.assertEqual(calc_discount(100, "vip"), 90.0)     def test_svip_gives_twenty_percent_off(self):        self.assertEqual(calc_discount(100, "svip"), 80.0)     def test_boundary_zero_price(self):        self.assertEqual(calc_discount(0, "vip"), 0.0)     def test_boundary_negative_price_raises(self):        with self.assertRaises(ValueError):            calc_discount(-0.01, "vip")     def test_invalid_level_raises(self):        with self.assertRaises(ValueError):            calc_discount(100, "boss")     def test_mock_notifier_verifies_call(self):        notifier = Mock()        notifier.send.return_value = True        price = calc_discount(200, "svip")        notifier.send(price)        notifier.send.assert_called_once_with(160.0)  if __name__ == "__main__":    unittest.main(verbosity=2)

1. def calc_discount(price, level):被测函数，根据会员等级计算折后价，是测试的靶心。
2. if price is None or price < 0:边界保护：空值和负数直接抛异常，这是无效等价类的处理入口。
3. rate = {"normal": 1.0, "vip": 0.9, "svip": 0.8}[level]折扣率映射表，字典取值时若 key 不存在会自动抛 KeyError。
4. def test_vip_gives_ten_percent_off(self):方法名以 test_ 开头，unittest 框架会自动发现并执行。
5. self.assertEqual(calc_discount(100, "vip"), 90.0)断言函数返回的实际值等于期望值，是测试的“法官”。
6. with self.assertRaises(ValueError):断言“应当抛异常”的场景，验证异常输入被优雅拒绝。
7. notifier = Mock()创建替身对象，模拟真实的通知服务，不真的发消息。
8. notifier.send.assert_called_once_with(160.0)行为验证：断言 send 方法恰好被调用一次，且参数是 160.0。

常见误区

面试题