单元测试是确保代码质量的重要手段，使用python的unittest模块可有效实现。1. unittest通过继承testcase类组织测试用例，每个以test_开头的方法为独立测试项；2. 提供多种断言方法如assertequal、asserttrue、assertraises等验证结果；3. setup()和teardown()用于测试前准备与测试后清理；4. 可直接运行脚本或用命令行批量执行测试文件，推荐以test*.py命名测试脚本。
单元测试是确保代码质量的重要一环，Python标准库中的unittest模块提供了非常实用的测试框架。如果你已经写好了功能函数，想验证它是否在各种情况下都能正常运行，用unittest是个不错的选择。
下面我们就来一步步了解怎么用unittest做单元测试。
写一个简单的测试类
unittest使用类的方式来组织测试用例。你需要继承unittest.TestCase，然后在这个类里面定义测试方法。
立即学习“Python免费学习笔记（深入）”；
import unittest
class TestMathFunctions(unittest.TestCase):
def test_addition(self):
self.assertEqual(1 + 1, 2)
if __name__ == '__main__':
unittest.main()上面这个例子虽然简单，但它展示了最基本的结构：
- 测试类继承自
unittest.TestCase - 每个以
test_开头的方法都会被当作一个测试用例执行 - 使用断言方法（如
assertEqual）来判断结果是否符合预期
你可以把每个要测试的功能函数都封装成一个测试方法，集中在一个类里管理。
常用的断言方法
unittest提供了多种断言方式，方便你检查不同类型的期望值。以下是一些常用的：
-
assertEqual(a, b)：检查 a 是否等于 b -
assertTrue(x)：检查 x 是否为 True -
assertIsNone(x)：检查 x 是否为 None -
assertIn(a, b)：检查 a 是否在 b 中 -
assertRaises(exception, callable, *args, **kwargs)：检查是否抛出了指定异常
比如你要测试一个除法函数，当除数为0时应该抛出异常，就可以这样写：
def divide(a, b):
if b == 0:
raise ValueError("除数不能为零")
return a / b
class TestMathFunctions(unittest.TestCase):
def test_divide_by_zero(self):
with self.assertRaises(ValueError):
divide(10, 0)这里用了上下文管理器 with self.assertRaises(...) 来捕获异常，这是处理异常断言的标准做法。
setUp 和 tearDown 的作用
有时候你在每次测试前需要做一些准备工作，比如连接数据库、初始化变量等；测试结束后可能还需要清理资源。这时候可以用到 setUp() 和 tearDown() 方法。
python内部自带了一个单元测试的模块，pyUnit也就是我们说的：unittest；本文档主要讲述的是python unittest基本介绍；感兴趣的朋友可以过来看看
class TestDatabase(unittest.TestCase):
def setUp(self):
# 初始化数据库连接或临时数据
print("准备测试环境")
def tearDown(self):
# 清理资源
print("清理测试环境")
def test_query(self):
# 这里可以调用数据库查询方法
pass-
setUp()在每个测试方法执行前自动运行 -
tearDown()在每个测试方法执行后自动运行
这两个方法非常适合用来统一处理前置条件和善后工作，避免重复代码。
怎么运行测试？
最简单的方式是在脚本中加上：
if __name__ == '__main__':
unittest.main()然后直接运行这个 Python 文件即可。
如果你想批量运行多个测试文件，或者希望输出更清晰的结果，可以使用命令行：
python -m unittest discover
这条命令会自动查找当前目录及其子目录下所有以 test*.py 命名的文件并运行它们。
另外，也可以加一些参数让输出更详细，例如：
python -m unittest discover -v
-v 表示 verbose，会显示每个测试用例的名称和结果。
基本上就这些了。刚开始写的时候不用太复杂，先从几个关键函数开始测试，熟悉断言和结构之后再逐步扩展。只要坚持写测试，你会发现 bug 更容易定位，代码也更有信心重构。
别忘了测试覆盖率也很重要，不过那是另一个话题了。
