java – Unittest包装器方法是否有意义

这个问题有些哲学.鉴于我有这样的方法：

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或其他框架,专业的测试方法是什么？

解决方法:

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

单元测试(在纯/严格意义上,单元通过模拟与其依赖关系隔离)被高估.这不只是我说的;像Kent Beck(TDD的主要“创造者”)和Martin Fowler这样的作者也不是“纯粹”单元测试的粉丝(例如,参见Is TDD Dead?).

模拟最好用于特殊情况,出于实际原因,如果没有它,你就不能轻易编写测试.根据我自己的经验,集成测试(没有或最少的模拟)已经证明要好得多.

标签：java,unit-testing,jmockit
来源： https://codeday.me/bug/20190528/1170011.html