https://pact.io logo
Join Slack
Powered by
hi all, are there any examples of provider tests w...
# general
u
hi all, are there any examples of provider tests when the provider is 100% AWS lambda code?
m
As in, can you do a provide test running against a lambda? 🤔
mm I don’t think so. I’ve done it in the past. Is it serving an HTTP interface (e.g. via gateway) or is it a direct lambda invocation?
l
So you can do this. We're currently using Connexion + Flask, running inside an AWS Lambda; which (in 2.x) uses something like 
aws-wsgi
to convert to and from Lambda event payload from API Gateway and from Flask responses. Locally it just runs regular Flask in Connexion. There are ASGI examples (for starlette, expressJS, golang etc) as well; it's usually googling your framework + lambda + adapter + apigateway For PACT specifically; I'd likely use a separate entrypoint (command to launch code), so that PACT can test locally and in pipelines. Just like other applications, you likely need to configure your app into a PACT compatible state (maybe some stubbed repositories or data access layer) Ironically I still find PACT the most complex part of this setup. Currently we're using more OpenAPI contract validation than PACT for this reason. Our OpenAPI is manually authored as a result so that we are not going to have accidental changes or breakages between releases.
u
Our OpenAPI is manually authored as a result so that we are not going to have accidental changes or breakages between releases. (edited)
❤️
I’ll reply in a moment, thanks for the info thouh
though
the team I’m helping tried to implement bidirectional, since they have a bunch of integ tests (semi-stubbed, etc.) that target their lambda code. However the OAS they’re working with is not supported by our pact broker (it uses 
oneOf
with mappings).
what I suggested to them was that they generate server stubs from their OAS and wire the lambda code to the endpoints and just be done with it (they’re still considering this option).
I also suggested they drop the use of 
oneOf
because it’s problematic anyway, but that’s a non-starter
and right now my fear is that due to this friction they might abandon CT altogether because “it’s hard”
l
So my rebuttal against "contract testing is hard" is that it is, but it's less hard than not contract testing
I cannot imagine why dropping one-of would be beneficial though. For this reason I would not have PACT use the OpenAPI, while PACT fixes it's support of valid OpenAPI
but it can still have manually authored cases written against an API using OpenAPI for runtime validation
u
right, I also don’t buy the “CT is hard” argument. I always challenge that with “think about the alternative”.
đź‘Ť 1
ref PACT + OAS, I’m generally against the idea of bidirectional anyway. The tech issue they’re running into is that the broker can’t makes sense of `oneOf`+`mappings` (discriminators), and so bidirectional is not working for them at all.
đź‘€ 1
what I’m looking for now is a small/simple thin layer they can put in front of their business logic and do standard provider verifications instead
2 Views
Open in Slack
PreviousNext
Powered by