写Python单元测试时，最让人头疼的往往不是写不出用例，而是用例跑红了却不知道错在哪。很多初学者习惯在测试函数里疯狂加print，或者把断言注释掉一步步试，这种做法不仅低效，还会让测试代码变得脏乱。实际上，Python生态里的unittest和pytest都提供了成体系的调试能力，理解它们背后的机制，可以让我们像调试普通脚本一样调试测试。
使用pdb进行交互式调试
pdb是Python标准库自带的交互式调试器。在单元测试中，我们不需要修改业务代码，只需控制测试的运行方式即可进入pdb。对于基于unittest的测试，可以直接用模块方式启动：python -m pdb test_module.py，程序会在第一时间暂停，此时可用n单步、s进入函数、c继续。
如果只想在测试失败时才调试，可以在测试代码里主动插入断点。Python 3.7+提供了内置函数breakpoint()，它默认调用pdb。下面这段unittest示例展示了如何在断言前停下来检查状态：
import unittest
def add(a, b):
return a + b
class TestAdd(unittest.TestCase):
def test_add_negative(self):
x = 1
y = -2
breakpoint() # 运行到这里会进入pdb
result = add(x, y)
self.assertEqual(result, -1)
if __name__ == '__main__':
unittest.main()
这种方式的优点是零配置，缺点是断点是硬编码的，调试完容易忘记删除。因此在CI环境或提交前，应当把breakpoint()清理掉，或者改用更灵活的环境变量控制。
pytest的--pdb与--trace参数
pytest对调试的支持更加顺手。当用例失败时，加上--pdb参数，pytest会在异常抛出处自动拉起pdb会话，你可以直接查看局部变量、调用栈。相比之下，unittest需要自己捕捉异常才能进调试器，pytest则天然集成。
另一个实用参数是--trace，它会在每个测试用例开始时立即中断，适合排查setUp逻辑的问题。以下命令演示了基本用法：
# 失败即调试 pytest test_sample.py --pdb # 每个用例入口都停 pytest test_sample.py --trace
在pdb界面中，推荐使用ll查看当前行附近代码，用p 变量名打印值，用w看调用栈。这样能迅速判断是测试用例预期写错，还是被测函数逻辑偏离。pytest还支持--pdbcls指定其他调试器，比如ipdb，获得语法高亮体验。
用日志代替print观察过程
大量print不仅干扰unittest的输出版面，还会在pytest参数化运行时产生刷屏效应。更规范的做法是使用logging模块，在测试基类或setUp中配置级别，在业务代码里用logger输出，而不是裸print。
下面示例展示如何在unittest里统一配置日志，让调试信息只在需要时出现：
import unittest
import logging
logging.basicConfig(level=logging.DEBUG)
logger = logging.getLogger(__name__)
def divide(a, b):
return a / b
class TestDivide(unittest.TestCase):
def setUp(self):
logger.debug('setUp run')
def test_divide(self):
logger.debug('before divide')
r = divide(10, 2)
logger.debug('result is %s', r)
self.assertEqual(r, 5)
if __name__ == '__main__':
unittest.main()
通过命令行控制LOG_LEVEL环境变量，我们可以在不改代码的情况下开关调试日志。这比在代码里增删print稳妥，也不会因忘记清理而影响他人阅读。对于异步或多线程测试，logging的线程安全特性也比print更可靠。
借助IDE与覆盖率定位盲点
除了命令行调试，PyCharm、VS Code等工具允许在测试文件上直接点断点运行。它们的变量面板比pdb文本界面直观，适合复杂对象检查。同时，配合coverage.py查看哪些分支没被测试覆盖，也能反向提示我们：没覆盖到的代码往往就是隐藏bug的地方。
安装与使用覆盖率工具十分简单：
pip install coverage coverage run -m pytest coverage report -m
报告中缺失的行号，可以指导我们补充针对性用例，并在对应用例里用前面提到的pdb或日志手段验证其行为。把调试方法和覆盖率结合，单元测试就从“写完就跑”变成了“跑不通也能快速修”的良性循环。
常见误区与建议
一个典型误区是：测试红了就改被测函数，却从不确认测试本身对不对。调试时应先核实测试输入与预期是否符合需求，再去看实现。另一个误区是在CI里留着breakpoint，导致流水线卡死。建议本地调试用breakpoint，提交前用pytest --pdb一次性排查，确认无误后移除硬断点。
总结来看，Python单元测试调试并不神秘：标准库pdb解决通用问题，pytest参数让失败现场触手可及，logging让过程可视且干净，IDE与覆盖率补足工程化视角。把这些方法组合起来，就能摆脱盲目试错的泥潭。