However, if you're using

aws-sdk-mock

, then you're probably not sending real requests. So, pact will be unhappy, because it wants the real request

However, if you're using pact against the AWS sdk, you'll be in for a bad time, because the HTTP calls that that AWS SDK makes aren't part of the API contract

what are you trying to do?

(or are you using message pacts?)

What you would usually do is spin up your provider (in this case, you probably deploy it to your test env, or wherever) and then run the pact verifier against it

In this way, there would be no

aws-sdk-mock

, because you're spinning up your real provider

however, if the lambda requires anything upstream, like a DB or other AWS services, you may want to mock those using the pact state change

usually I would do this as the first step in your lambda - where you would normally configure all those connectors, you just configure mock ones instead

alternatively, you can not deploy it, and test it locally. Then you could use aws-sdk-mock, I guess

it all depends on how your lambda is getting the http event

er

Pact needs to call the actual endpoint

that's what's under test

aws-sdk-mock

is for mocking out aws sdk calls - I assumed that your lambda is calling some AWS services, but do you mean that you're using it to mock the whole lambda invocation?

I think I'm confused about what you're trying to do

here's the code snippet.

test('Should invoke the ConsumeLambda.', () => {
    AWSMock.setSDKInstance(AWS);
    AWSMock.mock('Lambda', 'invoke', function mockedInvoke(params, callback) {
      callback(null, {
        Payload: {
          statusCode: 200,
          body: {
            message: 'This token is valid',
            metadata: {}
          }
        }
      });
    });

    return invokeConsumeLambda('token', 'VALIDATE').then(data => {
      expect(data).toMatchObject({
        statusCode: 200,
        body: {
          message: 'This token is valid',
          metadata: {}
        }
      });
    });
  });

it sounds like maybe there's no API gateway, and you're invoking the lambda directly?

invokeConsumeLambda

<-- I think this is using the mock set up, rather than invoking it directly

what's happening here is that you're marking your own exam

"hey, I'm gonna mock this, so it returns X" "now I'll call it and check it returns X"

redundant test

The test shouldn't be entirely redundant, because usually

invokeConsumeLambda

would do things like: • Know how to make the call • Know how to marshal the request (eg

getUser(29)

becomes

GET /some/path/user/29

) • Know how to unmarshall the response

however, since the code is expecting the exact response from the AWS sdk, I think there's no unmarshalling going on

Other nice things about pact: • You only test the things you need - so in this case, the

metadata: {}

is returned. I bet you don't need it, so you don't need to tell pact about it

• You're testing that your client really can send the request

That last point is nice, because it means that you catch things like incorrectly invoked http library.

note that your consumer test doesn't actually hit the real provider

then when you go to test the provider, your real provider will be invoked by pact

real consumer -> pact pact -> real provider

because i dont know what the endpoint is.

Yeah. This is the problem with using pact to test the AWS sdk. The requests are opaque

Similarly, you don't need to test the AWS connection part of the AWS SDK

However, in this case, I think: • You could continue with aws-sdk-mock, but you want some way to know that the mocked response is what the real lambda produces • The returned value from

aws-sdk-mock

suggests that the design of the layers could be improved • If you can change the design to bring in an API gateway, then you can just make an HTTP request as normal. Then you can use pact, and also your consumer implementation doesn't even need to know it's contacting AWS

The returned value from aws-sdk-mock suggests that the design of the layers could be improved

Because the calling layer knows that it's a lamdba API response object. It shouldn't know that - probably it should just get

{
          message: 'This token is valid',
          metadata: {}
        }

(although I don't know your application, so it's hard to say for sure) - this is unrelated to pact / aws-sdk-mock - it's just something I noticed