简体   繁体   中英

Seperate Pact Interactions in Provider Verification Tests by Endpoint

I just started to adopt Pact test for my system that consists of one provider service and an Angular frontend as the consumer. I succeeded in setting up both sides, thus, the Angular application generates a (single) pact file with many interactions to multiple endpoints of my provider service. In the provider, I do now face the issue that my verification test gets very large and overly complicated since I have to mock all my endpoints in a single test with all their data, eg:

@Provider("example-backend")
@PactFolder("pacts")
@SpringBootTest(...)
class ComprehensivePactTest {

    [...]

    @State("healthy")
    fun `healthy state`() {
        whenever(exampleService.dosomething(any())).thenReturn(exampleResponse)
        whenever(otherService.somethingElse()).thenReturn(otherResponse)
    }
}

Is there a way to seperate the interaction from the pact file such that I could have multiple small verification tests in my provider? For instance, I would like to have a verification test for all requests with path starting with "/example" and a second test for path starting with "/other".

So what I would prefer to have is smaller, focused verification test like so:

@Provider("example-backend")
@PactFolder("pacts")
@SpringBootTest(...)
class ExampleEndpointPactTest {

    [... include some filter logic here ...]

    @State("healthy")
    fun `healthy state`() {
        whenever(exampleService.dosomething(any())).thenReturn(exampleResponse)
    }
}

@Provider("example-backend")
@PactFolder("pacts")
@SpringBootTest(...)
class OtherEndpointPactTest {

    [... include some filter logic here ...]

    @State("healthy")
    fun `healthy state`() {
        whenever(otherService.somethingElse()).thenReturn(otherResponse)
    }
}

Or do I have a fallacy in my thinking? Thanks.

The JUnit4 Readme has a section about this topic. I think it also applies to Junit5 https://github.com/DiUS/pact-jvm/tree/master/provider/pact-jvm-provider-junit#using-multiple-classes-for-the-state-change-methods

Using multiple classes for the state change methods

If you have a large number of state change methods, you can split things up by moving them to other classes. There are two ways you can do this: Use interfaces

You can put the state change methods on interfaces and then have your test class implement those interfaces. See StateAnnotationsOnInterfaceTest for an example. Specify the additional classes on the test target

You can provide the additional classes to the test target with the withStateHandler or setStateHandlers methods. See BooksPactProviderTest for an example.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM