# Python unittest 那些事
它是什么
Python标准库里的unittest，本质上是一个测试框架的骨架。就像盖房子先搭脚手架，unittest提供了TestCase、TestSuite这些基础构件。很多人第一次接触它，会觉得这东西怎么这么啰嗦——写个测试还得继承类、写方法、用断言。但用久了会发现，这种“啰嗦”恰恰是它最实在的地方：结构清晰，每个测试用例都是独立的，跑错了也不会互相影响。
有个同事刚开始用unittest时，总喜欢把所有测试塞到一个函数里，觉得这样省事。结果某天改了个功能，跑测试时一堆报错，根本分不清哪个用例出了问题。后来规规矩矩按unittest的规则来，每个功能点一个测试方法，问题定位快多了。
它能做什么
unittest能干的事，说白了就是三件：确认代码行为符合预期、保证修改不破坏已有功能、作为文档告诉后来人这段代码该怎么用。
举个例子，你写了个计算购物车总价的函数：
defcalc_total(items):returnsum(item['price']*item['qty']foriteminitems)用unittest可以这样验证：
classTestCart(unittest.TestCase):deftest_empty_cart(self):self.assertEqual(calc_total([]),0)deftest_single_item(self):items=[{'price':10,'qty':2}]self.assertEqual(calc_total(items),20)deftest_mixed_items(self):items=[{'price':10,'qty':2},{'price':5,'qty':3}]self.assertEqual(calc_total(items),35)这些测试不光验证了函数对不对，更向读代码的人展示了：空购物车返回0、单价和数量分开传入、多商品累加。比看注释靠谱得多。
怎么使用
实际项目中，unittest的使用有几个关键点需要注意。先说组织方式，建议按模块建测试文件，比如tests/test_cart.py、tests/test_user.py，这样结构清晰。每个测试文件里，一个类对应一个功能模块。
setUp和tearDown是容易被忽略但很有用的东西。比如测试数据库操作时，可以在setUp里创建临时数据库连接，tearDown里清理数据：
classTestUserDB(unittest.TestCase):defsetUp(self):self.db=create_test_database()self.db.add_user('test_user')deftearDown(self):self.db.drop_all()deftest_get_user(self):user=self.db.get_user('test_user')self.assertEqual(user.name,'test_user')另一个实用技巧是使用skip装饰器。有时某个测试依赖外部服务，服务挂了整个测试套件就跑不了。用@unittest.skipIf可以优雅跳过：
@unittest.skipIf(notnetwork_available(),'网络不可用')deftest_api_call(self):response=requests.get('https://api.example.com/status')self.assertEqual(response.status_code,200)最佳实践
写了好几年unittest，总结了几条实际经验：
测试和方法一一对应。一个测试方法只测一件事。比如测登录功能，不要在一个方法里既测密码正确又测密码错误又测验证码过期。分开写，出错了看方法名就知道哪有问题。
断言要具体。别用assertTrue(result)这种模糊的断言。用assertEqual、assertIsNone、assertRaises这些明确的断言，测试失败时错误信息会直接告诉你预期和实际值的差异。
测试也要重构。如果多个测试方法里出现重复代码（比如都创建同一个mock对象或者初始化相同数据），抽到setUp里或者写成辅助方法。我见过最极端的情况，一个测试文件300行，200行是重复的数据准备代码，真正的测试逻辑只有100行。
测试数据和测试逻辑分离。把测试用的输入数据和预期结果抽成列表或字典，用循环生成测试。这样维护成本低很多：
test_cases=[({'price':10,'qty':2},20),({'price':5,'qty':0},0),({'price':-1,'qty':1},-1),]foritem,expectedintest_cases:withself.subTest(item=item):self.assertEqual(calc_total([item]),expected)这个subTest特别实用，一个测试方法里循环测多组数据，失败了还能精确知道是哪组数据出了问题。
和同类技术对比
说到测试框架，绕不开pytest。两者差异挺明显：
入门门槛。unittest需要写类、继承、写断言方法，有种“先学规矩再干活”的感觉。pytest用普通函数、assert语句，更贴近日常Python写法。如果团队里有新手，pytest上手快得多。
fixture机制。pytest的fixture是它的杀手锏。同样是连接数据库，unittest要用setUp/tearDown围绕一个类作用域，pytest可以精细控制fixture的作用域（模块级、类级、函数级），还能在fixture之间依赖。这种灵活性在复杂测试场景下很有优势。
插件生态。pytest有pytest-cov（覆盖率）、pytest-xdist（并行执行）、pytest-html（报告）等丰富插件。unittest虽然也能集成这些功能，但大多是依赖第三方库额外配置，不如pytest开箱即用。
选择建议：如果是写库或者框架，追求零依赖，unittest是唯一选择（毕竟标准库自带）。如果是公司项目、Web服务这类应用，pytest往往更高效。但坦白说，理解unittest的原理对理解pytest有很大帮助——pytest本质上是对unittest理念的现代化重构。
选哪个最终看项目风格和团队习惯。有次维护一个古老项目，测试全是unittest写的，硬改成pytest反而带来了风险。在那之后，我更倾向于“不主动替换”原则：现有项目保持测试框架不变，新项目评估后选合适的。
