我正在努力减少代码的单一性，使其成为更小/更容易理解的单元，但我不确定测试的最佳实践是什么。这里有一个例子：
def a(some_input):
...
def b(other_input):
# Bunch of logic, possible other function calls
if some_condition:
a(...)
测试a对我来说似乎很简单，但当涉及到b时，我应该测试当b被输入调用时，导致它调用a调用a(在python中，这有点像Mock.assert_called_with，还是我应该只是测试输出是否正确？
我对此的看法是，让我们说重新使用a，并打破a；我认为这是一堆假阳性测试失败，因为周围的逻辑/行为是正确的，应该简单地修复a。
测试记录的输出和副作用。
例如，如果A只是进行一个子计算，这有助于B的输出，那么B的单元测试应该忽略它。A是一个内部实现细节，可以随时更改，B甚至可能停止调用A；如果实现发生更改，则测试中断。只应对记录在案的B的返回值进行测试。CCD_ 10或其他什么。
假设A是一个发送电子邮件的东西。这是调用B的一个记录在案的副作用，应该进行测试。与其设置一个假邮件服务器等等，不如模拟对a的调用，并测试B是否传递了正确的值。A将单独进行单元测试。如果A足够复杂，你可以把A分成一个单独的对象，只发送电子邮件，让B使用A的实例。
在分解良好的代码中，每个子系统都由它们自己的对象管理。假设B正在合计销售价格，而a正在进行复杂的税务计算。A应该是自己的对象，只做税收计算，单元测试A。当单元测试B时，B并不真正关心A返回什么，只要包括税收。B的单元测试可以模拟A返回一个固定值，并测试A的税收值。B的结果中包括A和B。经过彻底的单元测试，你可以做一个简单的集成测试，调用B和真实的A。