如何在不预设类数据属性名称的情况下编写Python单元测试？

其实核心思路很简单：单元测试应该聚焦于类的对外行为和契约，而不是内部的属性名称——毕竟属性属于实现细节，哪天开发者重构改个名字，你的测试就挂了，但类的功能其实没坏，这就本末倒置了。

下面给你具体的实践方法和例子：

1. 围绕类的公共方法与行为编写测试 #

不管内部用了什么属性名，类对外暴露的方法才是用户（或者其他代码）会用到的部分。咱们就盯着这些方法的输入、输出和副作用来写测试。

比如你的CreditCard类，不管内部是用_balance还是_current_debt，它的核心行为肯定是：

• 初始化后有信用额度
• 消费不超额度时成功
• 消费超额度时失败
• 还款后恢复可用额度

那对应的测试用例就可以这么写（用unittest框架举例）：

import unittest

class TestCreditCard(unittest.TestCase):
    def setUp(self):
        # 只需要知道初始化时传信用额度，不用管内部存成啥属性
        self.card = CreditCard(credit_limit=1200)

    def test_initial_charge_within_limit_succeeds(self):
        # 测试初始状态下消费1000（小于额度1200）应该成功
        self.assertTrue(self.card.charge(1000))

    def test_charge_exceeding_limit_fails(self):
        # 先消费1000，再消费300，总额1300超额度，应该失败
        self.card.charge(1000)
        self.assertFalse(self.card.charge(300))

    def test_payment_restores_credit(self):
        # 消费1000后还款500，再消费700刚好到额度，应该成功
        self.card.charge(1000)
        self.card.make_payment(500)
        self.assertTrue(self.card.charge(700))

    def test_over_payment_resets_balance_to_zero(self):
        # 消费500后还600，之后应该能全额使用1200额度
        self.card.charge(500)
        self.card.make_payment(600)
        self.assertTrue(self.card.charge(1200))

你看，这些测试完全没碰内部属性，哪怕后来把_balance改成_outstanding_amount，把_credit_limit改成_max_allowance，测试依然能正常通过——因为类的行为没变。

2. 万不得已时用反射（但尽量避免） #

如果某些场景下你必须验证内部状态，而类又没提供公共的getter方法，那可以用Python的反射机制来“探知”内部属性，但这是退而求其次的办法，因为它依赖实现细节，很脆弱。

比如你可以用dir()获取所有属性名，再通过关键字匹配找到目标属性，用getattr()取值验证：

def test_internal_initial_state(self):
    # 不推荐，但特殊场景下可以用
    card_attrs = dir(self.card)
    # 找包含"balance"或"debt"的属性（小写匹配，兼容不同命名）
    balance_attr = next(attr for attr in card_attrs if any(key in attr.lower() for key in ["balance", "debt"]))
    # 找包含"limit"或"credit"的属性
    limit_attr = next(attr for attr in card_attrs if any(key in attr.lower() for key in ["limit", "credit"]))
    
    self.assertEqual(getattr(self.card, balance_attr), 0)
    self.assertEqual(getattr(self.card, limit_attr), 1200)

但要注意：如果哪天开发者把属性名改成完全不沾边的（比如_owed或_cap），这个测试就会报错。所以除非必要，别这么干。

总结 #

写单元测试的核心原则是测试“做了什么”，而不是“怎么做的”。聚焦行为的测试不仅更健壮，还能帮你明确类的设计——如果一个类的状态无法通过公共方法验证，那可能说明它的接口设计有问题，应该考虑添加必要的公共方法来暴露状态（比如get_available_credit()）。

内容的提问来源于stack exchange，提问作者Salro