java - 在单元测试中使用 SpringRunner 可以吗？

Question

我们正在与我的同事讨论这种方法。他们说仅在集成或功能级别使用 SpringRunner。

问题是在以下级别使用它的利弊是什么？

例如我有简单的 bean :

public class RewardDurationCalculator {

    private Clock clock;

    public OptionalLong calculate(DurationType durationType, List<Pass> passes) {
        long now = Instant.now(clock).getEpochSecond();
        switch (durationType) {
            case FULL_PASS:
                return getCurrentPassDuration(passes, now);
            case TILL_THE_END_OF_THE_CURRENT_ACTIVE_PASS:
                return getTimeInCurrentPassLeft(passes, now);
        }
        return OptionalLong.empty();
    }

    private OptionalLong getCurrentPassDuration(List<Pass> passes, long now) {
        return passes.stream()
                .filter(currentPass(now))
                .mapToLong(Pass::getDuration)
                .findFirst();
    }

    private OptionalLong getTimeInCurrentPassLeft(List<Pass> passes, long now) {
        return passes.stream()
                .filter(currentPass(now))
                .mapToLong(pass -> getEndTs(pass) - now)
                .findFirst();
    }

    private Predicate<Pass> currentPass(long now) {
        return pass -> pass.getStartTs() >= now && now <= getEndTs(pass);
    }

    private long getEndTs(Pass pass) {
        return pass.getStartTs() + pass.getDuration();
    }

}

那是在做一些计算逻辑。为此，我也有 Spring 配置:

@Configuration
public class RewardDurationCalculatorConfiguration {

    @Bean
    public RewardDurationCalculator rewardDurationCalculator(Clock clock) {
        return new RewardDurationCalculator(clock);
    }

}

那么为什么我不能像这样为它编写单元测试:

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = RewardDurationCalculatorConfiguration.class)
public class RewardDurationCalculatorTest {

    @MockBean
    private Clock clock;
    @Autowired
    private RewardDurationCalculator rewardDurationCalculator;

    @Test
    public void testCalculateCurrentPassDurationShouldBeReturnedIfPassWasCreatedRightNow() {
        rewardDurationCalculator.calculate(DurationType.FULL_PASS, Collections.emptyList());
    }

}

使用这种方法我会面临什么缺点？

Answer 1

我倾向于同意你的同事的看法。

单元测试应该只测试小的代码单元，通常是单个类。他们应该只执行被测单元，而不执行单元依赖项中的任何代码。

原因之一是单元测试应该尽可能快地执行。在测试驱动开发 (TDD) 中，您希望能够运行套件，或者至少是其中的一个相关子集，经常在您做出每一个小的更改之后，以验证您没有破坏任何现有行为。只有当测试的反馈是即时的时，这才是可行的。如果您必须等待测试结果的时间过长，那么运行它们的频率就会降低，这意味着反馈循环会变长。

在较小的 Spring 项目中，Spring 上下文加载速度非常快，因此您可能认为没有太大区别，但是如果您经常运行测试，即使很短的延迟也会增加。在大型和较旧的代码库中，可能需要一段时间来提升 Spring 上下文，并且在某些时候它会变得如此缓慢，以至于您不想每天多次运行整个测试套件，这会大大损害您的能力实践TDD。

坚持测试小代码单元的另一个方面是它迫使您将代码结构化为高度解耦(即可测试)的单元。如果你不能为一个只练习那个类而没有其他东西的类编写单元测试，这可能暗示有机会改进代码的设计。

总而言之，当您为测试增加整个 Spring 上下文时，根据这个定义，它不再是单元测试，而是集成测试，因为您还在测试整个 Spring 配置、引导、 Autowiring 等，即。 e.将您的类集成到 Spring 应用程序中。