Unittest包装器方法是否有意义？ [英] Does it make sense to Unittest wrapper methods
问题描述
这个问题有点哲学。鉴于我有这样的方法：
This question is somewhat philosophical. Given i have a Method like this:
public List<String> getStuffByName(@NotNull String name) throws SomeException {
return someDependency.createQuery().byName(name).list().stream()
.map(execution -> execution.getProcessInstanceId())
.collect(Collectors.toList());
}
基本上它只是调用依赖方法然后使用流处理它api。
Basically all it does is call a dependencies method and then process it using the stream api.
单元测试 - 严格理解（？） - 仅测试一个隔离单元。
所以我会模拟依赖项，因为我认为它们本身也已经过测试单位。
A Unittest - in a strict understanding(?) - is only testing one isolated unit. So i would Mock the dependencies, as i assume they also are already tested units themselves.
如果我完成这个，我最终会得到一个方法它完全由在别处测试的东西组成。
If I go through with this, i end up with a Method that exclusively consists of stuff that is tested elsewhere.
例如我的JMockit测试看起来像这样：
Eg my JMockit Test would look like this:
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);
}
但是这个测试真的告诉我什么？
But what does this test really tell me?
在测试驱动开发中，我会省略对这种包装方法的测试吗？
In test-driven-development, would i omit tests of such "wrapper" methods?
测试这种方法的专业方法是什么？ ，独立于Jmockit或其他框架？
What would a professional approach to test this be, independent of Jmockit or other frameworks?
推荐答案
测试这个的专业方法将是 not 模仿任何东西。一个好的测试应该尽可能真实，同时保持足够快速和稳定。
A "professional approach" to test this would be to not mock anything. A good test should be as realistic as you can make it, while also keeping it sufficiently fast and stable.
单位测试（纯粹的/严格意义上，单位通过模拟与其依赖关系隔离）被高估。这不只是我说的;像Kent Beck（TDD的主要创造者）和Martin Fowler这样的作者也不是纯粹单元测试的粉丝（参见 TDD是否死亡？，例如）。
Unit tests (in the pure/strict sense, where the unit is isolated from its dependencies through mocking) are overrated. This isn't just me saying it; authors like Kent Beck (the main "creator" of TDD) and Martin Fowler are no fans of "pure" unit testing either (see Is TDD Dead?, for example).
模仿最适用于特殊情况，出于实际原因你不能没有它就能轻松编写测试。根据我自己的经验，集成测试（没有或最小的模拟）已经证明要好得多。
Mocking is best used in exceptional cases, where for practical reasons you just can't easily write the test without it. In my own experience, integration tests (with no or minimal mocking) have proved to be much better.
这篇关于Unittest包装器方法是否有意义？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
