unit-testing - tdd - 我应该在这里模拟还是使用真正的实现

Question

我正在编写程序参数解析器，只是为了在 TDD 中变得更好，但我遇到了以下问题。假设我的解析器定义如下:

class ArgumentsParser {
    public ArgumentsParser(ArgumentsConfiguration configuration) {
        this.configuration = configuration;
    }

    public void parse(String[] programArguments) {
        // all the stuff for parsing
    }
}

我想像这样实现 ArgumentsConfiguration:

class ArgumentsConfiguration {
    private Map<String, Class> map = new HashMap<String, Class>();

    public void addArgument(String argName, Class valueClass) {
        map.add(argName, valueClass);
    }

    // get configured arguments methods etc.
}

这是我现在的阶段。现在在测试中我使用:

@Test
public void shouldResultWithOneAvailableArgument() {
    ArgumentsConfiguration config = prepareSampleConfiguration(); 
    config.addArgument("mode", Integer.class);
    ArgumentsParser parser = new ArgumentsParser(configuration);
    parser.parse();
    // ....
}

我的问题是这样的方式是否正确？我的意思是，可以在测试中使用真正的 ArgumentsConfiguration 吗？还是我应该 mock 它？默认(当前)实现非常简单(只是包装了 Map)，但我想它可能会更复杂，比如从某种数据源中获取配置。那么 mock 这种“昂贵”的行为是很自然的。但是这里的首选方式是什么？

编辑:也许更清楚:我应该在不编写任何实现的情况下模拟 ArgumentsConfiguration(只定义其公共(public)方法)，使用模拟进行测试并稍后处理实际实现，还是应该在测试中使用最简单的，让他们覆盖这个间接实现。但如果是这样，那么测试另一个稍后提供的 Configuration 实现呢？

Answer 1

Then it'd be natural to mock such "expensive" behaviour.

这不是重点。您不是在模拟复杂的类。

你在 mock 完全隔离类。

完全隔离确保测试证明类遵循它们的接口(interface)并且没有隐藏的实现怪癖。

此外，完全隔离使得调试失败的测试变得非常非常容易。它要么是测试，要么是被测类，要么是模拟对象。理想情况下，测试和模拟非常简单，不需要任何调试，只留下被测类。