Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mocks are not reset between nested tests if WebFluxTest has properties set #34629

Closed
denvir opened this issue Mar 17, 2023 · 2 comments
Closed
Assignees
Labels
status: duplicate A duplicate of another issue type: bug A general bug

Comments

@denvir
Copy link

denvir commented Mar 17, 2023

Affects: both latest 2.7.9 and 3.0.4

If properties are defined in WebFluxTest and nested test classes are used, mocks are not reset between tests:

@WebFluxTest(controllers = DataController.class, properties = "property=value")
@TestClassOrder(ClassOrderer.OrderAnnotation.class)
class FailingTest {

  @Autowired
  private WebTestClient webTestClient;

  @MockBean
  private DataService service;

  @BeforeEach
  void setUp() {
    given(service.get()).willReturn("test");
  }

  @Nested
  @Order(1)
  class WhenExecutingFirstRequest {

    @BeforeEach
    void setUp() {
      webTestClient.get().uri("/data1").exchange();
    }

    @Test
    void thenVerifyServiceCall() {
      verify(service).get();
    }

    @Test
    void thenVerifyServiceCallAgainInSameNestedClass() {
      verify(service).get(); //fails because invocation from earlier test is counted as well
    }
  }

  @Nested
  @Order(2)
  class WhenExecutingSecondRequest {

    @BeforeEach
    void setUp() {
      webTestClient.get().uri("/data2").exchange();
    }

    @Test
    void thenVerifyServiceCallInSiblingNestedClass() {
      verify(service).get(); //fails because invocations from earlier tests are counted as well
    }
  }
}

It only affects nested test classes. There is no issue if used without nested classes like this:

@WebFluxTest(controllers = DataController.class, properties = "property=value")
class NotNestedTest {

  @Autowired
  private WebTestClient webTestClient;

  @MockBean
  private DataService service;

  @BeforeEach
  void setUp() {
    given(service.get()).willReturn("test");
  }

  @Test
  void shouldCallServiceOnFirstRequest() {
    webTestClient.get().uri("/data1").exchange();
    verify(service).get();
  }

  @Test
  void shouldCallServiceOnSecondRequest() {
    webTestClient.get().uri("/data2").exchange();
    verify(service).get();
  }
}

Example project: run with mvn clean package.
The only difference between WorkingTest and FailingTest is that FailingTest defines one property for tests whereas WorkingTest does not:
@WebFluxTest(controllers = DataController.class, properties = "property=value") vs @WebFluxTest(controllers = DataController.class)
webflux-nested-test-with-properties.zip

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 17, 2023
@ianbrandt
Copy link

I believe I just hit this same issue:

https://github.com/sdkotlin/sd-kotlin-spring-talks/blob/213f5745bee7543b7ff26ffebd610100230bbc30/subprojects/child-context/rest-api/src/it/kotlin/org/sdkotlin/springdemo/childcontext/rest/ChildContextControllerIT.kt#L42

If I run test create for service exception()—which stubs a service exception—before test create(), the latter fails on that service exception. They pass the other way around.

Seems to impact both Mockito and Ninja-Squad/springmockk.

Possibly related: #23984 and #12470.

@wilkinsona
Copy link
Member

Thanks for the report and minimal sample, @denvir. This is a duplicate of #33317 that I have just fixed in 2.7.x onwards.

@wilkinsona wilkinsona closed this as not planned Won't fix, can't repro, duplicate, stale Mar 27, 2023
@wilkinsona wilkinsona added type: bug A general bug status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue type: bug A general bug
Projects
None yet
Development

No branches or pull requests

4 participants