CODEWITHSUNDEEP
microservicesopenapipact
EaterOfFromage
EaterOfFromage

Reputation: 319

Using Pact with a generated Client Api Service

I'm currently investigating Pact as part of the development of a testing strategy. It's a microservices architecture, and there are various server-to-server connections where I can see it being expectionally useful (including messaging queues).

However, one place I'm having trouble understanding exactly how it should work is the connection between the client and server. In our most common pattern, we have a single Java microservice that acts as the server for a Typescript/Angular web client. The server utilizes an OpenAPI specification; specifically, we manually write the OpenAPI spec file, then generate both server and client code from the spec file - the server code is a series of interfaces for controllers we're expected to implement, and the client code is a library of services and models that the client can use to make requests to the server. This pattern on the client makes HTTP requests a breeze, for several reasons:

  1. The models and controllers are defined in the spec file and shared between the client and server, meaning we have static enforcement of contracts, so we know if the contract is broken before we even run the tests
  2. Interacting with the server is a breeze because the generated controller service has an easy to use API that abstracts away the details of host name, paths, etc.

On one hand, there a few things we could definitely stand to gain from using Pact in this setup:

  1. The pact file can be used to start a stub server, which can then be used to support component testing.
  2. It moves us more towards a consumer-driven contract approach (which is generally good, but only if we're actually enjoying benefits from it).

On the other hand, I have a few concerns:

  1. We don't really have need for the syntactic enforcement provided by Pact at test time, since we have that at compile time.
  2. Consumer testing following the guidelines established in the Pact docs would essentially involve testing the generated service code, which feels... wrong. There should be no need to test generated code - it should just work. And since our contract tests should reflect actual client behaviour, the only scenarios where one of these tests would fail (e.g., making a breaking change to the API) will always coincide with a compile-time failure in our implementation, thus making the tests unnecessary.
  3. Even if we were to write all the tests, it's not clear what action we would take on the provider side. We could validate the pact against the OpenAPI definition, but I'm pretty sure there's no possible way we could fail such a validation given our setup (short of manually modifying the pact file, which seems like a big no-no). Admittedly, I haven't done much investigation on the provider side yet though.

Frankly, the first positive alone is enough for me to commit to Pact. The consumer-driven approach makes the process of generating stubs make SO much more sense. That being said, the negatives definitely wear on me. It feels like a lot of work, where much of it is introducing redundant verification mechanisms, so that we can eke a single benefit out.

Am I approaching this wrong? Is there a simple change I could make to this approach to get the same benefits without introducing the redundancies? Or do I just need to accept that this is the way?

Edit: So I started investigating tooling around using pacts to generate stub servers and it turns out it's pretty lacking. The built-in pact server stub doesn't support programmatically adding mocks to the running server, and most of the libraries I found that converting pact for use with other server stub libraries are pretty small and not particularly well maintained. Meaning we might have to build our own solution for that stubbing process, which makes Pact even less appealing =/

Upvotes: 5

Views: 1012

Answers (1)

Matthew Fellows
Matthew Fellows

Reputation: 4065

So there is a lot here!

First up, here is why a schema is not a contract and some of the things you should be wary of when treating them as such: https://pactflow.io/blog/schemas-are-not-contracts/

The most notable gap in your reasoning above (if I've understood correctly) is that you need to ensure the client/server libraries stay in sync, particularly during a release phase (sharing implementations was common with SOAP, and it's easy to have moments in time where the provider has a version that is not compatible with the consumer, therefore requiring both components to be deployed simultaneously)

As for programmatically creating stubs, you can do it: https://github.com/pact-foundation/pact-mock_service/blob/master/script/example.sh

But why not just use a library that can turn an OAS into a stub server?

Upvotes: 3

Related Questions