Unittest 包装器方法是否有意义

Question

这个问题有点哲学。鉴于我有一个这样的方法：

public List<String> getStuffByName(@NotNull String name) throws SomeException {
        return someDependency.createQuery().byName(name).list().stream()
                .map(execution -> execution.getProcessInstanceId())
                .collect(Collectors.toList());
}

基本上它所做的就是调用一个依赖项方法，然后使用流 api 处理它。

单元测试 - 严格理解（？） - 只测试一个孤立的单元。所以我会模拟依赖项，因为我认为它们本身也是经过测试的单元。

如果我这样做，我最终会得到一个只包含在其他地方测试过的东西的方法。

例如，我的 JMockit 测试看起来像这样：

public void test_get_processes_for_bkey_2(@Mocked ExecutionQuery query,
                                              @Mocked List<String> processes,
                                              @Mocked List<Execution> executions,
                                              @Mocked Stream<Execution> e_stream,
                                              @Mocked Stream<String> pid_stream,
                                              @Mocked Stream<String> pdef_stream

    ) {
    new Expectations() {
        {
            someDependency.createQuery(); result = query;
            query.byName("somefilter"); result = query;
            query.list(); result = executions;
            executions.stream(); result = e_stream;
            e_stream.map((Function) any); result = fin_stream;
            fin_stream.collect((Collector) any); result = processes;
            processes.size(); result = 2;
        }
    };

    assertEquals(tested.getStuffByName("somefilter").size(), 2);
}

但是这个测试真正告诉我什么？

在测试驱动开发中，我会省略对这种“包装器”方法的测试吗？

独立于 Jmockit 或其他框架的专业测试方法是什么？

Answer 1

测试这一点的“专业方法”是不要嘲笑任何东西。一个好的测试应该尽可能真实，同时还要保持足够的快速和稳定。

单元测试（在纯粹/严格意义上，单元通过模拟与其依赖项隔离）被高估了。这不仅仅是我说的；像 Kent Beck（TDD 的主要“创造者”）和 Martin Fowler 这样的作者也不喜欢“纯”单元测试（例如，参见Is TDD Dead？）。

模拟最好用于特殊情况，出于实际原因，如果没有它，您将无法轻松编写测试。根据我自己的经验，集成测试（没有或最少的模拟）被证明要好得多。

Answer 2

该方法的约定是执行具有给定名称的查询，并返回查询返回的执行实例的流程实例 ID。您的方法是否使用流、for 循环或任何其他操作都无关紧要。

所以我只会存根查询并使其返回 2 或 3 次执行的真实列表。根据查询返回的列表，我将检查返回的列表是否包含正确顺序的适当的 2 或 3 个 ID。