存在依赖关系的类方法的单元测试（Unittest）最佳实践探讨

我完全理解你现在的纠结——当类的方法彼此依赖时，到底该怎么写单元测试才既规范又高效？毕竟单元测试的核心是“单元”，但实际场景里方法间的依赖又让拆分变得棘手。咱们先把你提到的ToDoList类贴出来，方便后续分析：

class ToDoList:
    def __init__(self):
        self._bullet_points: list[str] = []  # 管理一个简单的字符串列表

    def add_bullet_point(self, string: str):
        check_something(string)  # 假设这里有更复杂的校验逻辑
        self._bullet_points.append(string)

    def get_bullet_point(self, index: int):
        return self._bullet_points[index]

    def reverse_list(self):
        self._bullet_points = list(reversed(self._bullet_points))

接下来逐个拆解你提到的几种方案，聊聊各自的优劣和适用场景：

方案1：单测试用例全覆盖（高效但非纯“单元”） #

先看代码实现：

def test_behavior(todo_list: ToDoList):
    test_string_1 = 'This is a test.'
    test_string_2 = 'This is another test.'
    todo_list.add_bullet_point(test_string_1)
    todo_list.add_bullet_point(test_string_2)
    
    assert test_string_1 == todo_list.get_bullet_point(0)
    assert test_string_2 == todo_list.get_bullet_point(1)
    
    todo_list.reverse_list()
    assert test_string_1 == todo_list.get_bullet_point(1)
    assert test_string_2 == todo_list.get_bullet_point(0)

优缺点分析 #

• 优点：代码简洁高效，一次测试就能验证类的核心行为，执行速度快，适合快速验证整体功能是否正常，比如在开发初期做冒烟测试。
• 缺点：不符合单元测试“隔离单一逻辑”的经典定义。如果测试失败，你得逐个排查是add、get还是reverse出了问题，定位bug的成本很高。而且后续修改任意一个方法的逻辑，都可能影响整个测试用例的结果，维护灵活性不足。

方案2：拆分独立测试用例（纯“单元”但可优化冗余） #

代码实现如下：

def test_add_bullet_point(todo_list: ToDoList):
    test_string = 'This is a test.'
    todo_list.add_bullet_point(test_string)
    assert test_string == todo_list._bullet_points[0]  # 原代码笔误修正：需取索引0

def test_get_bullet_point(todo_list: ToDoList):
    test_string = 'This is a test.'
    todo_list.add_bullet_point(test_string)
    assert test_string == todo_list.get_bullet_point(0)

def test_reverse_list(todo_list: ToDoList):
    test_string_1 = 'This is a test.'
    test_string_2 = 'This is another test.'
    todo_list.add_bullet_point(test_string_1)
    todo_list.add_bullet_point(test_string_2)
    
    assert test_string_1 == todo_list.get_bullet_point(0)
    assert test_string_2 == todo_list.get_bullet_point(1)
    
    todo_list.reverse_list()
    assert test_string_1 == todo_list.get_bullet_point(1)
    assert test_string_2 == todo_list.get_bullet_point(0)

优缺点分析 #

• 优点：严格遵循单元测试的隔离原则，每个用例只验证一个方法的逻辑。如果某个测试失败，能立刻定位到对应的方法，排查问题精准。后续修改单个方法时，只需要更新对应测试用例即可，维护性好。
• 缺点：存在代码冗余——每个测试都要重复调用add_bullet_point准备数据。不过这个问题可以用分层fixture解决：

  @pytest.fixture
  def todo_list_with_single_item():
      todo = ToDoList()
      todo.add_bullet_point('This is a test.')
      return todo
  
  @pytest.fixture
  def todo_list_with_two_items():
      todo = ToDoList()
      todo.add_bullet_point('This is a test.')
      todo.add_bullet_point('This is another test.')
      return todo
  

  这样test_get_bullet_point可以直接用todo_list_with_single_item，test_reverse_list用todo_list_with_two_items，彻底消除重复代码。

方案3：共享对象+测试依赖（高效且拆分，但依赖插件） #

先修改fixture的作用域，再编写测试用例：

# 修改fixture
import pytest

@pytest.fixture(scope="session")
def todo_list():
    return ToDoList()

# 测试用例
def test_add_bullet_point(todo_list: ToDoList):
    test_string = 'This is a test.'
    todo_list.add_bullet_point(test_string)
    assert test_string == todo_list._bullet_points[0]

@pytest.mark.depends(on=['test_add_bullet_point'])
def test_get_bullet_point(todo_list: ToDoList):
    assert 'This is a test.' == todo_list.get_bullet_point(0)

@pytest.mark.depends(on=['test_get_bullet_point'])
def test_reverse_list(todo_list: ToDoList):
    todo_list.add_bullet_point('This is another test.')
    todo_list.reverse_list()
    assert 'This is a test.' == todo_list.get_bullet_point(1)
    assert 'This is another test.' == todo_list.get_bullet_point(0)

优缺点分析 #

• 优点：既拆分了测试用例，又通过共享fixture避免了重复初始化和数据准备，执行效率高。测试依赖标记能保证执行顺序，符合方法的调用逻辑。
• 缺点：依赖第三方插件pytest-dependency，增加了项目的依赖成本。而且共享状态会导致测试用例耦合——如果前置测试修改了对象状态，后续测试会受影响；一旦前置测试失败，所有依赖的测试都会被跳过，可能掩盖其他潜在问题。另外，session/module级别的fixture无法自动重置状态，第二次运行测试时对象不是初始状态，可能导致结果不一致。

方案4：Mock隔离依赖（更纯粹的单元测试） #

还有一种方案是用Mock隔离方法间的依赖，比如测试get_bullet_point时，不需要真的调用add_bullet_point，直接Mock私有属性的状态：

from unittest.mock import patch

def test_get_bullet_point_mocked(todo_list: ToDoList):
    test_string = 'This is a test.'
    # 直接Mock私有属性的状态
    with patch.object(todo_list, '_bullet_points', [test_string]):
        assert test_string == todo_list.get_bullet_point(0)

def test_reverse_list_mocked(todo_list: ToDoList):
    test_items = ['test1', 'test2']
    with patch.object(todo_list, '_bullet_points', test_items.copy()):
        todo_list.reverse_list()
        assert todo_list._bullet_points == ['test2', 'test1']

优缺点分析 #

• 优点：完全隔离了每个方法的依赖，真正做到了“单元”测试。不需要依赖其他方法的执行，测试用例独立且可重复。即使add_bullet_point出问题，也不会影响get或reverse的测试。
• 缺点：需要掌握Mock的使用技巧，对新手有学习成本。如果类的内部实现变更（比如私有属性改名），Mock代码需要同步修改，维护成本增加。另外，过度Mock可能会忽略方法间的交互逻辑，比如get_bullet_point依赖add的隐藏校验逻辑时，Mock就无法覆盖这种场景。

总结建议 #

没有绝对的“最佳方案”，要根据项目规模和需求选择：

1. 小型项目或快速原型：优先选方案1，快速高效，覆盖核心功能。
2. 中大型项目追求可维护性：选方案2+分层fixture，消除冗余的同时保持测试独立性，便于bug定位。
3. 对测试效率要求极高且能接受插件依赖：可以尝试方案3，但要注意测试顺序和状态重置，避免耦合问题。
4. 需严格隔离单元逻辑：选方案4的Mock方式，但要平衡Mock粒度，避免脱离实际业务逻辑。

另外提醒一点：单元测试要验证行为而非实现。比如测试add_bullet_point时，尽量通过get_bullet_point断言结果，而不是直接校验私有属性_bullet_points——这样即使后续内部存储方式变更，测试用例也不需要修改。

备注：内容来源于stack exchange，提问作者N. Jonas Figge