单元测试私有方法遇困境：仅测试公共接口是否更优？

很多技术讨论都倡导通过公共接口测试私有方法，核心观点是：

通过编写公共方法的测试用例来覆盖私有方法的测试。

我在新项目中遵循这一最佳实践，编写了如下公共validate方法：

def validate(self, otherArgs, ...):
  self._validateOneThing(args)
  self._validateAnotherThing(args)
  ...

我未直接测试_validateOneThing、_validateAnotherThing等私有方法，而是通过公共的validate接口完成测试，且仅有validate方法会被其他类调用。但实践中遇到两大棘手问题：

• 无关参数填充导致的测试维护成本飙升
  例如我编写了如下validate方法：

  def validate(self, files, format, dataType):
    self._validateDatatype(dataType)
  

  对应的测试代码为：

  def test_validateDataType(self):
      validator = Validator()
      with self.assertRaises(ValidationError):
        validator.validate("dummy1", "C", "dummy2")
  

  因最初未明确files和format的规范，我使用了随机dummy值。后续新增format校验逻辑后，所有针对dataType的旧测试均因dummy格式不合法全部失效，需逐一修改，在大型代码库中会耗费大量工时。若直接测试私有方法，则只需传入该方法所需参数，无需处理无关组件。

• Mock管控的边界难题
  我编写了包含os.path.exists(myFile)调用的私有方法_validateFile，为避免依赖文件系统，使用了如下Mock：

  @patch('os.path.exists', return_value=True)
  

  该全局Mock会使所有os.path.exists调用返回True，但此前测试中使用的dummy文件实际不存在，因此需为所有测试应用该Mock。若校验逻辑中多个私有方法均包含os.path.exists调用，则无法单独管控每个方法的Mock行为，循环场景下更难以处理。

我试图理解仅测试公共接口相较于直接测试私有方法的优势，但实践中问题频发、测试维护成本极高，恳请相关技术指导。

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