首页 文章

使用@WebMvcTest的Spring Boot Test在Atlassian Bitbucket Pipeline上失败

提问于
浏览 次
2

在本地运行一些 @WebMvcTest 时，我没有问题（Spring Boot 1.5.8，gradle 4.6）：

@RunWith(SpringRunner.class)
@WebMvcTest(VZNFCController.class)
public class VZNFCControllerTest {

  private VZNFCTagAction action1 = new VZNFCTagAction();
  private VZNFCTagAction action2 = new VZNFCTagAction();

  @Before
  public void setUp(){
      action1.setMessage("message1");
      action2.setMessage("message2");
  }


  @Autowired
  private MockMvc mvc;

  @MockBean
  private VZNFCTagActionRepository actionRepository;

  @MockBean
  private MappingMongoConverter mongoConverter;

  @Test
  @WithMockUser
  public void testGetTagList() throws Exception {

    given(this.actionRepository.findAll())
              .willReturn(Arrays.asList(action1, action2));  
    this.mvc.perform(get("/api/nfc/tags")
            .accept(MediaType.APPLICATION_JSON_UTF8))
            .andExpect(status().isOk());
    }
}

但是，当我上传到Atlassian Bitbucket并在那里运行 ./gradlew test --stacktrace 时，我得到以下内容：

java.lang.IllegalStateException: Failed to load ApplicationContext
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:124)
at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:83)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:117)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
at org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:44)
at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:230)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:228)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:287)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:289)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:247)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.

现在Bibucket管道使用Docker Image（java：8） . 当我在本地切换回 @SpringBoot 和 @AutoConfigureMockMvc 时，我在两个环境中都得到了相同的错误 . 两个环境中的相同数据库设置（MongoDB的相同docker镜像），相同的一切......使用Docker时，是否有些端口无法映射？我想我确实创建了Servlet请求......

EDIT

在Docker容器中模拟Bitbucket管道构建（如建议here），似乎嘲笑 MappingMongoConverter 并与 @AutoConfigureMockMvc 一起移动到 @SpringBootTest 足以让它运行 . 所以 @WebMvcTest 只有部分模拟的上下文就足够了，没有容器，但它会在Docker容器中失败，例如使用Bitbucket时存在的容器 . 为什么？

java spring spring-boot bitbucket-pipelines spring-mvc-test

1 回答

  • 0

    事实证明有一些关键的bean缺失了，因为 @WebMvc 注释不会拿起 @Components ，只有网络堆栈不包括存储库所需的，但问题是我的安全配置，我想要测试，我现在只是 @Import （以及控制器依赖的其他一些bean：

    @RunWith(SpringRunner.class)
@WebMvcTest(value = VZNFCController.class)
@Import(value = {VZApiSecurityConfiguration.class, 
                 VZJwtTokenUtils.class, VZProperties.class})
public class VZNFCControllerTest {

  @Autowired
  private MockMvc mvc;

  @MockBean
  private VZNFCTagService tagService;

  /* same as the above... I don't mock out the repository any more */

}

    这里学到的经验是，所有自动配置的测试上下文（ @WebMvc ， @DataMongoTest 等）都会加速你的测试（这很好，因为我在bitbucket上支付了构建时间） . 但是你需要真正了解运行应用程序片段所需的内容 . 它迫使我真的只是模拟服务专注于控制器，然后为我的应用程序的DAO部分编写更多测试 . 我猜这是件好事 .

    回复于

相关问题