1. 项目概述：为什么说“会写测试”是合格Python开发者的分水岭？

最近在带新人，发现一个挺普遍的现象：很多刚学完Python语法、能写点小脚本的朋友，一提到“写测试”就犯怵，要么觉得是测试工程师的活儿，要么觉得写测试代码浪费时间，不如直接运行看结果。直到他们的脚本在凌晨三点因为一个边界条件崩溃，或者改了一行代码却导致三个看似不相关的功能同时报错时，才意识到测试的重要性。今天，我就以一个过来人的身份，掰开揉碎了讲讲Python测试入门这件事。这不是什么高深的理论，而是每个想靠Python吃饭的开发者都必须掌握的“生存技能”。它能让你写的代码更可靠，改代码时更有底气，和别人协作时更顺畅。我们不讲虚的，就从一行最简单的断言开始，手把手带你写出你的第一段测试代码，并理解其背后的逻辑。

简单来说，Python测试就是写一段代码，去验证另一段代码（你的业务逻辑）是否按照你的预期工作。它就像你产品的“质检员”，在代码出厂前自动完成检查。无论你是做数据分析、Web开发、自动化脚本还是机器学习模型，测试都是保证代码质量的最低成本手段。这篇文章适合所有Python初学者，以及那些写过代码但从未系统写过测试的朋友。我会用最直白的例子，带你绕过我当年踩过的坑，快速上手。

2. 测试基础认知：单元测试、断言与测试框架

在动手写代码之前，我们得先统一一下“语言”。不然我说“写个单元测试”，你可能理解成“跑一遍脚本看看”。这里面有几个核心概念必须搞清楚。

2.1 什么是单元测试？

单元测试，顾名思义，就是对软件中最小的可测试单元进行检查和验证。在Python中，这个“单元”通常是一个函数或者一个类的方法。它的目标是隔离程序的每个部分，并证明这些独立的部分是正确的。一个关键原则是 隔离性 ：测试一个函数时，不应该受到数据库、网络、文件系统或其他函数的影响。举个例子，你写了一个计算商品打折后价格的函数 calculate_discount(price, rate) 。单元测试就是针对这个函数，用不同的价格和折扣率去调用它，看它返回的结果是不是你心算出来的那个数。

为什么强调单元？因为只有把测试粒度做细，当测试失败时，你才能迅速定位到是哪个具体的函数出了错。如果是一大段代码混在一起测，一个报错可能让你排查半天。

2.2 断言：测试的“判决书”

断言（Assert）是测试代码的核心语句。它的作用就是做出一个“判断”，如果判断为真，测试通过；为假，则测试失败，并抛出异常。在Python中，最简单的断言就是使用 assert 关键字。

# 一个极其简单的断言例子
result = 1 + 1
assert result == 2, f“预期结果是2，但实际得到了{result}”

上面代码的意思是：我断言 result 的值等于2。如果等于，程序静默通过；如果不等于，则抛出 AssertionError 异常，并显示后面的错误信息。在测试中，我们会用断言来验证被测试函数的返回值是否符合预期。

2.3 Python自带的测试框架：unittest

Python标准库自带了一个强大的测试框架 unittest ，它提供了测试用例（TestCase）、测试套件（TestSuite）、测试运行器（TestRunner）等完整结构。虽然社区还有 pytest 这样更流行的第三方框架，但 unittest 是官方的，无需安装，结构清晰，是入门的最佳选择。它模仿了Java的JUnit，使用面向对象的方式来组织测试。

它的基本套路是：

1. 创建一个继承自 unittest.TestCase 的类。
2. 在这个类里，每一个以 test_ 开头的方法都会被识别为一个独立的测试用例。
3. 在测试方法内部，使用 TestCase 类提供的各种断言方法，比如 self.assertEqual() , self.assertTrue() 等，来代替原生的 assert ，这样能获得更丰富的失败信息。

了解这些基础概念后，我们就可以开始搭建环境，进入实战了。

注意 ：很多新手会混淆“运行脚本”和“运行测试”。运行脚本是执行你的业务逻辑；运行测试是执行你的测试代码，由测试代码去调用业务逻辑并验证。它们是两套不同的代码。

3. 环境准备与第一个测试用例实战

我们不搞复杂的项目结构，就在一个文件夹里，用最简单的例子把流程跑通。请确保你的电脑上已经安装了Python（3.6以上版本为宜）。

3.1 创建项目文件

首先，我们创建一个名为 python_test_demo 的文件夹，并在里面创建两个Python文件：

1. calculator.py ：这是我们的“业务代码”，里面包含要测试的功能函数。
2. test_calculator.py ：这是我们的“测试代码”，里面包含对 calculator.py 的测试。

你的文件夹结构应该像这样：

python_test_demo/
├── calculator.py
└── test_calculator.py

3.2 编写被测试的业务代码

打开 calculator.py ，我们写一个简单的四则运算计算器类，故意留一点小问题，方便后面演示测试如何发现Bug。

# calculator.py
class Calculator:
    """一个简单的计算器类，包含加减乘除方法。"""

    def add(self, a, b):
        """返回两个数的和。"""
        return a + b

    def subtract(self, a, b):
        """返回第一个数减去第二个数的结果。"""
        return a - b

    def multiply(self, a, b):
        """返回两个数的乘积。"""
        return a * b

    def divide(self, a, b):
        """返回第一个数除以第二个数的结果。"""
        if b == 0:
            # 注意：这里我们暂时简单返回None，实际应该抛出异常
            return None
        return a / b

注意看 divide 方法，当除数为0时，我们返回了 None 。这其实是一个不太好的设计，因为调用者可能忘记检查返回值，导致后续计算出错。更合理的做法是抛出 ZeroDivisionError 异常。我们暂且这样写，看看测试如何揭露这个问题。

3.3 编写第一个单元测试

现在，打开 test_calculator.py ，开始编写测试。我们将使用 unittest 框架。

# test_calculator.py
import unittest
# 导入要测试的类
from calculator import Calculator

class TestCalculator(unittest.TestCase):
    """测试Calculator类的各个方法。"""

    # 在每个测试方法运行前都会执行，用于准备测试环境
    def setUp(self):
        self.calc = Calculator() # 创建一个Calculator实例，供所有测试方法使用

    # 测试加法
    def test_add(self):
        result = self.calc.add(10, 5)
        self.assertEqual(result, 15) # 断言结果等于15
        # 可以多测几个边界情况
        self.assertEqual(self.calc.add(-1, 1), 0)
        self.assertEqual(self.calc.add(0, 0), 0)

    # 测试减法
    def test_subtract(self):
        self.assertEqual(self.calc.subtract(10, 5), 5)
        self.assertEqual(self.calc.subtract(5, 10), -5)

    # 测试乘法
    def test_multiply(self):
        self.assertEqual(self.calc.multiply(3, 4), 12)
        self.assertEqual(self.calc.multiply(0, 100), 0)

    # 测试除法 - 正常情况
    def test_divide_normal(self):
        self.assertEqual(self.calc.divide(10, 2), 5)
        self.assertAlmostEqual(self.calc.divide(10, 3), 3.33333333, places=7) # 浮点数比较使用assertAlmostEqual

    # 测试除法 - 除数为零的情况
    def test_divide_by_zero(self):
        result = self.calc.divide(10, 0)
        self.assertIsNone(result) # 断言结果为None

# 如果直接运行这个脚本，则执行测试
if __name__ == '__main__':
    unittest.main()

我来逐段解释一下：

1. import unittest 和 from calculator import Calculator 是导入必要的模块。
2. class TestCalculator(unittest.TestCase): 定义了一个测试类， 必须 继承 unittest.TestCase 。
3. setUp 方法是一个特殊的“夹具”（fixture），它会在 每一个 以 test_ 开头的方法执行 之前 被调用。这里我们用它来初始化一个 Calculator 对象，这样每个测试方法都能得到一个干净的、新创建的计算器实例，测试之间不会相互干扰。这是保证测试隔离性的关键一步。
4. test_add , test_subtract 等方法就是我们的测试用例。方法名 必须 以 test_ 开头，这样 unittest 才能自动发现它们。
5. 在测试方法内部，我们使用 self.calc 调用业务方法，并用 self.assertEqual() 等断言方法验证结果。 unittest 提供了丰富的断言方法，比直接用 assert 语句信息更友好。
   • assertEqual(a, b) ： 判断 a == b
   • assertTrue(x) ： 判断 bool(x) is True
   • assertIsNone(x) ： 判断 x is None
   • assertAlmostEqual(a, b, places=7) ： 判断浮点数 a 和 b 在指定位数（places）内是否相等，这是处理浮点数精度问题的利器。
6. 最后的 if __name__ == '__main__': unittest.main() 是一个常见模式。它表示如果直接运行这个Python文件（而不是被导入），就启动 unittest 的测试主程序。

3.4 运行测试并解读结果

现在，打开终端（命令行），进入到 python_test_demo 文件夹，运行测试：

python -m unittest test_calculator.py

或者，因为你已经在 test_calculator.py 底部写了 unittest.main() ，也可以直接运行这个文件：

python test_calculator.py

你会看到类似如下的输出：

.....
----------------------------------------------------------------------
Ran 5 tests in 0.001s

OK

每个点 . 代表一个通过的测试用例。5个点表示我们写的5个 test_ 方法都通过了！恭喜你，完成了第一个完整的测试套件。

实操心得 ：养成在终端看测试结果的习惯。 OK 和 FAIL 那一瞬间的反馈，是开发中最有成就感也最让人安心的事情之一。 setUp 方法用好了能极大减少重复代码，但要注意，不要在里面做耗时太长的操作，以免影响测试速度。

4. 深入测试技巧：异常测试、参数化与Mock

通过了基础测试，我们来看看更实际、更复杂的情况。真实的业务代码不会总是 add(2,2) 这么简单。

4.1 测试异常行为

还记得我们 calculator.py 里那个设计不佳的 divide 方法吗？它应该在除数为零时抛出异常，而不是返回 None 。让我们先修改业务代码，让它更健壮。

# calculator.py 修改divide方法
def divide(self, a, b):
    """返回第一个数除以第二个数的结果。"""
    if b == 0:
        raise ZeroDivisionError(“除数不能为零！”) # 改为抛出异常
    return a / b

现在，我们的测试代码也需要相应修改。我们需要测试“当除数为零时，是否正确地抛出了 ZeroDivisionError 异常”。 unittest 提供了 assertRaises 方法来处理这种情况。

修改 test_calculator.py 中的 test_divide_by_zero 方法：

# test_calculator.py 修改测试除零的方法
def test_divide_by_zero(self):
    # 使用assertRaises断言调用self.calc.divide(10,0)会抛出ZeroDivisionError
    with self.assertRaises(ZeroDivisionError) as context:
        self.calc.divide(10, 0)
    # 你还可以进一步检查异常信息
    self.assertEqual(str(context.exception), “除数不能为零！”)

with self.assertRaises(ZeroDivisionError): 这个上下文管理器意味着：在 with 块中的代码 应该 抛出一个 ZeroDivisionError 。如果抛出了，测试通过；如果没抛出，测试失败。 context.exception 可以让我们获取到抛出的异常对象，便于进一步验证异常信息。

再次运行测试，你会发现 test_divide_by_zero 依然通过，但这次它验证的是异常抛出行为，这比检查返回 None 要严谨得多。

4.2 使用参数化减少重复代码

观察之前的 test_add 方法，我们为了测试多组数据，写了三行 self.assertEqual 。如果测试数据有几十组，代码就会变得冗长。 unittest 本身不直接支持参数化测试，但我们可以通过 subTest 上下文管理器或者使用第三方库（如 parameterized ）来实现。这里介绍使用 subTest 的方法，它是标准库的一部分。

# test_calculator.py 使用subTest参数化测试加法
def test_add_with_subtest(self):
    test_cases = [
        (10, 5, 15),
        (-1, 1, 0),
        (0, 0, 0),
        (1.5, 2.5, 4.0),
    ]
    for a, b, expected in test_cases:
        with self.subTest(a=a, b=b, expected=expected):
            result = self.calc.add(a, b)
            self.assertEqual(result, expected)

使用 subTest 的好处是，当其中一组数据测试失败时，其他组的数据依然会继续执行，并且测试报告会清晰指出是哪一组数据失败了。这比在循环里直接写断言要友好得多。

4.3 模拟外部依赖：unittest.mock

单元测试的核心原则是“隔离”。如果你的函数内部调用了数据库查询、网络请求、文件读写或者另一个复杂的类，直接测试就会变得缓慢且不稳定。这时就需要用到 Mock（模拟） 。Python的 unittest.mock 模块提供了强大的模拟对象功能。

假设我们有一个函数，功能是获取天气信息并给出穿衣建议：

# weather.py
import requests

def get_dressing_advice(city):
    """根据城市天气给出穿衣建议（依赖网络请求）。"""
    # 这是一个真实的外部API调用，在测试中我们不希望真的发起请求
    response = requests.get(f“https://api.weather.com/{city}”)
    if response.status_code == 200:
        data = response.json()
        temperature = data[‘temp’]
        if temperature > 25:
            return “穿短袖”
        elif temperature > 15:
            return “穿长袖”
        else:
            return “穿外套”
    else:
        return “获取天气失败”

测试这个函数时，我们不应该真的去访问 api.weather.com 。一来可能没网络，二来API可能收费或限流，三来天气数据实时变化，导致测试结果不稳定。我们需要模拟 requests.get 这个方法。

# test_weather.py
import unittest
from unittest.mock import patch, Mock
from weather import get_dressing_advice

class TestWeather(unittest.TestCase):

    @patch(‘weather.requests.get’) # 装饰器，模拟weather模块里的requests.get方法
    def test_get_dressing_advice_hot(self, mock_get):
        # 1. 准备模拟的响应对象
        mock_response = Mock()
        mock_response.status_code = 200
        mock_response.json.return_value = {‘temp’: 30} # 模拟返回的JSON数据

        # 2. 将模拟响应赋值给模拟的get方法的返回值
        mock_get.return_value = mock_response

        # 3. 调用被测试函数
        advice = get_dressing_advice(“Beijing”)

        # 4. 断言函数返回了正确的结果
        self.assertEqual(advice, “穿短袖”)
        # 5. （可选）断言模拟的get方法被以正确的参数调用了一次
        mock_get.assert_called_once_with(“https://api.weather.com/Beijing”)

    @patch(‘weather.requests.get’)
    def test_get_dressing_advice_failure(self, mock_get):
        mock_response = Mock()
        mock_response.status_code = 404 # 模拟请求失败
        mock_get.return_value = mock_response

        advice = get_dressing_advice(“UnknownCity”)
        self.assertEqual(advice, “获取天气失败”)

if __name__ == ‘__main__’:
    unittest.main()

关键点解析 ：

• @patch(‘weather.requests.get’) ： 这个装饰器会临时将 weather 模块中的 requests.get 函数替换成一个 Mock 对象。这个 Mock 对象会作为参数 mock_get 传入测试方法。
• Mock() ： 创建一个模拟对象。我们可以任意设置它的属性和方法。
• mock_response.json.return_value = ... ： 设置 mock_response 的 json 方法的返回值为一个字典。注意， json 本身也是一个被模拟的方法。
• mock_get.assert_called_once_with(...) ： 这是一个“断言”，它验证模拟的 get 方法是否被调用了一次，并且调用时的参数是否与预期一致。这是Mock测试中非常有用的一环，确保你的函数以正确的方式调用了外部依赖。

通过Mock，我们将一个依赖外部网络的函数，变成了一个完全可控、运行速度极快的单元测试。这是编写高质量、可维护测试代码的关键技能。

注意事项 ：Mock是一把双刃剑。过度Mock会导致测试与实现细节耦合过紧（比如你断言了函数内部调用了某个特定方法）。一旦内部实现重构（比如换了个函数名），即使功能不变，测试也会失败。Mock的目标是隔离不稳定和慢速的外部依赖，而不是模拟所有东西。对于纯逻辑代码，应尽量使用真实对象。

5. 测试的组织、运行与最佳实践

写了不少测试用例了，是时候考虑如何更好地组织它们，以及如何在项目中集成测试了。

5.1 测试发现与自动化运行

unittest 有一套默认的测试发现规则：

• 查找所有名称以 test 开头的文件和目录。
• 在这些文件中，查找所有继承自 unittest.TestCase 的类。
• 在这些类中，查找所有以 test_ 开头的方法。

你可以直接在项目根目录运行以下命令来发现并运行所有测试：

python -m unittest discover

discover 命令会自动递归查找当前目录及子目录下所有符合规则的测试文件并执行。这对于大型项目非常方便。

在PyCharm、VSCode等现代IDE中，都内置了强大的测试运行器。你通常可以在测试文件或测试方法旁边看到一个绿色的“运行”按钮，点击即可运行单个测试、单个测试类或全部测试。IDE还会用图形化界面展示通过/失败情况，并直接链接到出错的行，调试效率极高。我强烈建议你花点时间熟悉你所用IDE的测试功能。

5.2 测试覆盖率：你的测试到底测了多少？

写了测试，但你怎么知道你的测试是否充分？有没有哪个角落的代码从来没被测试过？这时就需要“测试覆盖率”工具。 coverage 是一个常用的Python库。

首先安装它：

pip install coverage

然后使用它来运行你的测试并生成报告：

# 运行测试并收集覆盖率数据
coverage run -m unittest discover
# 在终端打印简洁的报告
coverage report
# 生成更详细的HTML报告，可以在浏览器中查看
coverage html

coverage report 的输出会显示每个模块的覆盖率百分比，包括语句（Stmts）、分支（Branch）、函数（Func）和行（Lines）的覆盖情况。 coverage html 会生成一个 htmlcov 文件夹，打开里面的 index.html ，你可以看到高亮显示的代码，绿色表示被覆盖，红色表示未覆盖。

我的经验是 ：不要盲目追求100%的覆盖率，那通常成本极高且不现实。重点保证核心业务逻辑、复杂分支和边界条件有覆盖。覆盖率是一个很好的 指导工具 和 质量趋势指标 ，而不是一个必须达到的硬性目标。看到红色未覆盖的代码，你应该思考的是“这段代码重要吗？需要加测试吗？”，而不是“我必须把它变绿”。

5.3 编写可测试代码的技巧

好的测试往往源于好的代码设计。一些简单的设计原则能让你的代码更容易被测试：

1. 单一职责原则 ：一个函数只做一件事。像之前那个既获取天气又给出建议的函数，就可以拆分成 fetch_weather(city) 和 suggest_dressing(temperature) 两个函数。这样，测试 suggest_dressing 就完全不需要Mock网络请求了。
2. 依赖注入 ：不要在被测函数内部直接创建（ new ）或导入（ import ）它依赖的对象，而是通过参数传递进来。这给了测试时注入模拟对象的机会。

   # 不易测试
   def process_data():
       db = Database() # 内部创建依赖
       data = db.query(...)
       ...
   
   # 易于测试
   def process_data(db): # 依赖通过参数传入
       data = db.query(...)
       ...
   

3. 避免全局状态和副作用 ：函数的行为应该只由它的输入参数决定，而不是依赖于某个隐藏的全局变量。同时，尽量减少修改外部状态（如全局变量、写入文件等），如果必须，也将其作为依赖注入。

遵循这些原则，不仅是为了测试，本身也是编写清晰、可维护代码的最佳实践。

6. 从unittest到pytest：更现代的选择

当你熟悉了 unittest 的基本概念后，我强烈建议你了解一下 pytest 。它是目前Python社区最主流的测试框架，以其简洁的语法和强大的功能著称。

6.1 pytest的优势

• 更简洁 ：不需要写类，函数就是测试用例。断言直接用 assert 。

  # test_with_pytest.py
  from calculator import Calculator
  
  def test_add():
      calc = Calculator()
      assert calc.add(2, 3) == 5
  

• 丰富的夹具系统 ： pytest 的 @pytest.fixture 比 unittest 的 setUp/tearDown 更灵活、更强大，可以方便地在多个测试文件和类之间共享 setup 代码。
• 强大的参数化 ：内置支持，语法直观。

  import pytest
  @pytest.mark.parametrize(“a,b,expected”, [(1,2,3), (4,5,9)])
  def test_add(a, b, expected):
      calc = Calculator()
      assert calc.add(a, b) == expected
  

• 庞大的插件生态 ：有无数插件用于生成报告、并行测试、控制测试顺序等。

6.2 如何开始使用pytest

安装： pip install pytest 运行：在项目根目录直接执行 pytest 命令，它会自动发现并运行所有测试（文件名以 test_ 开头或 _test 结尾，函数名以 test_ 开头）。

对于新手，我的建议是： 先用 unittest 打好基础，理解测试用例、夹具、断言等核心概念。当你觉得 unittest 的写法有些繁琐时，再平滑过渡到 pytest 。 pytest 甚至可以直接运行用 unittest 写的测试用例，迁移成本很低。

7. 常见问题与排查技巧实录

在实际编写和运行测试的过程中，你肯定会遇到各种各样的问题。这里我记录了几个最常见的情况和解决办法。

7.1 测试文件无法导入业务模块

问题 ：运行 python -m unittest test_calculator.py 时，报错 ModuleNotFoundError: No module named ‘calculator’ 。 原因 ：Python的模块导入路径问题。当你在子目录运行测试，或者项目结构复杂时，经常遇到。 解决 ：

1. 确保在正确的目录运行 ：在包含 calculator.py 和 test_calculator.py 的目录下执行命令。
2. 设置PYTHONPATH ：在运行命令前临时设置环境变量。 PYTHONPATH=/path/to/your/project python -m unittest test_calculator.py
3. 修改导入语句 ：如果业务模块在上级目录，可以使用相对导入（ from .. import calculator ）或绝对导入（ from myproject.tools import calculator ），但这通常需要将项目包装成包（有 __init__.py ）。
4. 使用pytest ： pytest 对模块路径的处理通常更智能一些。

7.2 测试通过但实际功能有Bug

问题 ：所有测试都显示 OK ，但上线后用户反馈了Bug。 原因 ：测试用例覆盖不全，没有考虑到某些边界条件或异常流程。 排查 ：

1. 审查测试用例 ：对照Bug现象，检查是否有对应的测试用例。如果没有，立刻补上。这就是“测试驱动修复”。
2. 检查Mock是否过度 ：如果测试中大量使用了Mock，检查是否把实际有问题的部分也Mock掉了，导致测试绕过了真正的逻辑。
3. 检查测试数据 ：测试数据是否过于“理想化”？尝试用更随机、更接近真实场景的数据进行测试（可以使用 hypothesis 这类属性测试库）。

7.3 测试运行太慢

问题 ：随着测试增多，跑一遍完整的测试套件要等好几分钟。 优化 ：

1. 隔离慢速测试 ：将依赖网络、数据库、文件IO的测试标记为“慢速测试”。 pytest 可以用 @pytest.mark.slow 标记，然后通过 pytest -m “not slow” 只运行快速测试。在CI/CD流水线中，可以分开执行。
2. 使用Mock ：这是解决慢速测试的根本方法，用Mock替换掉所有外部依赖。
3. 并行测试 ： pytest 有 pytest-xdist 插件可以并行运行测试，充分利用多核CPU。
4. 优化测试夹具 ：检查 setUp 和 @pytest.fixture(scope=“session”) 的使用。对于耗时的初始化（如创建数据库连接），使用 scope=“session” 可以让它在所有测试中只执行一次，而不是每个测试一次。

7.4 测试随机失败（Flaky Tests）

问题 ：同一个测试，有时通过，有时失败，没有规律。 原因 ：这是最令人头疼的问题之一，通常源于：

• 依赖外部服务 ：网络波动、API限流。
• 依赖共享状态 ：测试之间没有完全隔离，比如使用了同一个全局变量或数据库表，一个测试修改了它，影响了另一个测试。
• 并发问题 ：测试中涉及多线程/多进程，时序不确定。
• 依赖时间或随机数 ：测试中使用了 time.sleep() 或 random ，导致行为不可预测。 解决 ：

1. 彻底隔离 ：确保每个测试都是独立的。使用 setUp 和 tearDown 正确地初始化和清理环境。
2. Mock外部依赖 ：这是治本之策。
3. 控制不确定性 ：对于时间，可以使用 unittest.mock.patch 来模拟 time.time ；对于随机数，可以固定随机种子。
4. 重试机制 ：对于确实无法消除的外部依赖波动（如第三方API），可以在测试框架层面或CI工具中配置失败重试，但这只是缓解，不是解决。

下表总结了一些典型问题与速查解决方案：

问题现象	可能原因	排查与解决思路
ImportError	模块路径错误	1. 确认运行目录 2. 设置 PYTHONPATH 3. 检查 __init__.py
测试通过，生产Bug	测试覆盖不足	1. 根据Bug反推，补充边界用例 2. 检查Mock是否掩盖了真实逻辑
测试运行缓慢	外部IO依赖多	1. 用Mock替换网络/数据库调用 2. 区分并标记慢速测试
测试随机失败	共享状态、外部依赖、并发	1. 强化测试隔离性 2. Mock外部服务 3. 固定随机种子 4. 避免测试中的 sleep
AssertionError 信息不清晰	使用原生 assert	改用 unittest 的特定断言方法，如 assertEqual , assertIn 等

写测试是一个需要持续练习和反思的技能。最开始可能会觉得麻烦，但当你养成了“先写测试，再写实现”或者“修改代码，先跑测试”的习惯后，你会发现它带来的信心和效率提升是巨大的。它不仅仅是“测试”，更是一种设计代码的思维方式。从今天这个简单的计算器测试开始，尝试在你下一个哪怕很小的脚本里加上几个测试用例，亲自感受一下它如何改变你的开发流程。