java - 对 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?)。

Mocking 最适合在特殊情况下使用，在这种情况下，出于实际原因，您无法在没有它的情况下轻松编写测试。根据我自己的经验，集成 测试(没有模拟或模拟最少)被证明要好得多。