对调用另一个方法的方法进行单元测试

Golang小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《对调用另一个方法的方法进行单元测试》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

对调用多个方法的方法进行单元测试的最佳方法是什么，例如：

modify(string value)
{
    if(value.Length > 5)  replaceit(value);

    else changeit(value);
}

此伪代码有一个修改方法，该方法（当前）调用 replaceit() 或 changeit()。我已经为 replaceit 和 changeit 编写了测试，因此编写新的修改测试将是 99% 相同的代码集。我需要测试它的想法，因为它将来可能会改变。

那么我要复制粘贴现有的测试代码吗？将测试代码移至公共函数？还有其他想法吗？我不确定这里的最佳实践。

解决方案

这是一个经典的基于状态的测试与基于行为的测试场景。

在这个极其简单的示例中，测试输出没有问题。但在某些时候，您会遇到执行后检查状态很复杂的测试。相反，您想要检查行为（例如，验证是否使用特定值调用了 Changeit）。

此时，您可能应该研究像 Rhino.Mocks (.Net) 或 Mockito (Java) 这样的模拟对象框架，并开始编写更多基于接口的代码。

您有多种选择。哪一个最好取决于您的问题中未明确的细节。

• 测试 modify 就像它是一个不相关的方法一样。优点：它可能在某个时候成为一个。
• 只需测试您的 if 语句是否正确。也就是说，只需进行足够的测试，以便测试迫使您编写所需的实现（其中调用 replaceit 和 changeit 只是可能工作的最简单实现。如果您正在练习 TDD，这应该是自然而然的优点：测试覆盖率高，无需太多重复工作。
• 子类和覆盖方法（这是《有效处理遗留代码》一书中的一种依赖破坏技术）：在您引入的仅用于测试目的的子类上测试该方法，该子类会覆盖 replaceit和 changeit 带有预设答案，或者设置传感变量（指示是否使用正确值调用该方法的变量）。优点：可能会简化（或不会）您的测试，有时甚至只是使测试成为可能。
• 为 replaceit 和 changeit 方法提取一个新类，包括该类的接口。测试 modify 时存根或模拟该接口。优点：可能会让您的设计更具可测试性和一般（或不是）更好的解耦/可重用。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《对调用另一个方法的方法进行单元测试》文章吧，也可关注golang学习网公众号了解相关技术文章。