对别名方法进行单元测试

本文关键字：单元测试 方法 别名 | 更新日期: 2023-09-27 18:33:01

对仅调用其他 2 个方法而没有逻辑的方法进行单元测试的最佳实践是什么？

internal ICollection<ObjA> FunctionA()
{
    IEnumerable<ObjB> b = _factory.FunctionB();
    return FunctionC(b);
}

_factory.FunctionB()和FunctionC(b)都有单元测试，所以如果这些方法坏了，我们就会知道。

我正在考虑伪造这两个函数，并且只进行单元测试，以确保从FunctionA()调用方法。但是，如果FunctionB()或FunctionC()发生变化，FunctionA()可能会成为误报。

对别名方法进行单元测试

我倾向于不对私有或内部方法进行单元测试，因为它们应该在对公共 API 进行单元测试时执行。

假设这是一个公共方法，我会进行测试，根据私有成员的状态_factory检查调用 FunctionA(( 时预期的返回值。假设您可以控制_factory的输出(通过它是可模拟的接口、可子类的基类，或者只是使用已知值实例化并传递到类的构造函数中(，您可以确保基于该初始输入获得 FunctionA 的预期输出。

如果您发现每次更新函数B或函数C时都收到误报，我会质疑为什么函数A存在。更可能的情况是，在函数 A 上中断的单元测试将导致您更改函数 A 的内部实现，因为对函数 B 和 FunctionC 的更改不再使它们适合函数 A 的实现，或者它们将导致您为这些函数添加单元测试以修复函数 A 中的间接中断。

在这个特定示例中，FunctionA 似乎只是一个包装器，用于使用内部工厂类已指定的数据源将 ObjB 转换为 ObjA。对于此特定场景，我将为 FunctionA 设置测试，以便在上层需求发生变化时(因为实施了有关如何将 ObjB 转换为 ObjA 的新规则(，以便我可以将新逻辑放在 FunctionA 或 FunctionC 中，具体取决于我认为哪个更合适。

例：

internal ICollection<ObjA> FunctionA()
{
    IEnumerable<ObjB> b = _factory.FunctionB();
    // in the future unit test may drive that a different implemetation is used 
    // based on some data about b.
    if(b.SomeCondition())
        return FunctionC(b);
    else
        return FunctionD(b);
}

或者可能是 C 需要更改

internal ICollection<ObjA> FunctionC(IEnumerable<ObjB> objBEnumerable)
{
    ICollection<ObjA> objACollection = initializeCollection();
    foreach(var objB in objBEnumerable)
    {
        //updated logic to create objA from objB goes here
        objACollection.Add(createdObjA);
    }
    return objACollection;
}

基本上，您的问题的答案是"这取决于"，但是如果函数B和C的覆盖范围已经很好，以防A需要在未来的第一个代码示例中转移，我会错误地编写一个可能毫无意义的测试。

相关文章：