了解如何利用Spock 1.2切片传统应用程序的Spring上下文,编写集成测试。
您是否曾经想过,要开始使用一些遗留应用程序,编写一些测试以了解正在发生的事情,并可能收到有关回归的通知? 当您想实例化单个类时,这种感觉会因NullPointerException
而失败。 6替换(有困难)依赖项之后,您以前从未听说过的类仍然存在一些错误。 听起来很熟悉?
有多种技术可以处理隐藏的依赖项。 有整本专门的书(可能还有几本我还没读过)。 有时,从集成测试开始并执行某些过程可能是可行的。 即使只是在我们的情况下完全不需要,查看仅设置上下文所需的奇特组件可能更为“有趣”。 谢谢(太宽和粗心使用) @ComponentScan
:)。
在测试环境中注入存根/模拟是一种作为紧急援助的方式(请参阅最后一段,有更好但更难的方法)。 对于想要在其上进行切割的每个依赖项(或实例化的每个不需要的bean),可以使用带有@Primary
批注的额外bean定义(通常是在进行此操作之前要三思而后行)的“ bean”定义来“手动”实现。顺便说说)。 @MockBean
放在测试中的某个字段上更方便,但是仍然需要在我们的测试中定义一个字段并在其上添加注释(5?10?15 bean?)。 Spock 1.2引入了一些@StubBeans
功能, @StubBeans
在这里可能有用。
它可以用来简单地提供一个类列表,这些类(可能)应在Spring测试上下文中用存根替换。 当然,在实例化实际对象之前(例如,防止在构造函数中使用NPE)。 多亏了这几行存根/模拟注入:
@RunWith(SpringRunner.class) //Spring Boot + Mockito
@SpringBootTest //possibly some Spring configuration with @ComponentScan is imported in this legacy application
public class BasicPathReportGeneratorInLegacyApplicationITTest { //usual approach@MockBeanprivate KafkaClient kafkaClientMock;@MockBeanprivate FancySelfieEnhancer fancySelfieEnhancerMock;@MockBeanprivate FastTwitterSubscriber fastTwitterSubscriberMock;@MockBeanprivate WaterCoolerWaterLevelAterter waterCoolerWaterLevelAterterMock;@MockBeanprivate NsaSilentNotifier nsaSilentNotifierMock;//a few more - remember, this is legacy application, genuine since 1999 ;)//...@Autowiredprivate ReportGenerator reportGenerator;@Testpublic void shouldGenerateEmptyReportForEmptyInputData() {...}
}
可以只替换为一(长)行:
@SpringBootTest //possibly some Spring configuration with @ComponentScan is imported in this legacy application
@StubBeans([KafkaClient, FancySelfieEnhancer, FastTwitterSubscriber, WaterCoolerWaterLevelAterter, NsaSilentNotifier/(, ... */])//all classes of real beans which should be replaced with stubs
class BasicPathReportGeneratorInLegacyApplicationITSpec extends Specification {@Autowiredprivate ReportGenerator reportGeneratordef "should generate empty report for empty input data"() {....}
}
(使用Spock 1.2-RC2测试)
值得一提的是@StubBeans
仅用于提供占位符。 在某种情况下,需要提供存根和/或调用验证@SpringBean
或@SpringSpy
(在Spock 1.2中也引入了)更好。 我在以前的博客文章中写了更多有关它的内容 。
有一个重要方面要强调 。 @StubBeans
在我们有一些“遗留”项目并希望快速开始编写集成回归测试以查看结果的情况下很方便使用。 但是,正如我的一位同事DarekKaczyński的总结所概括的那样,盲目更换在测试中“爆炸”的豆仅仅是“扫除地毯下的问题”。 在初始阶段之后,当我们开始了解正在发生的事情时,是重新考虑在生产环境和测试环境中创建上下文的好时机。 已经提到过的@ComponentScan
太宽泛,通常是万恶之源。 设置部分上下文并将其放在一起(如果需要)的能力是一个很好的起点。 使用@Profile
或条件Bean是测试中非常强大的机制(不仅限于此)。 @TestConfiguration
和适当的bean选择以改善上下文缓存是值得牢记的。 但是,我从本文开始介绍了Spock中的新机制,该机制在某些情况下可能会有用,并且我想使其简短。 在集成测试中可能还有另一篇更通用的博客文章,关于管理Spring上下文。 我必须认真对待它:)。
翻译自: https://www.javacodegeeks.com/2018/09/integration-testing-legacy-application-spock-1-2.html