Best way to test handlers without actually deploying

[pocesar]

Might be out of the scope of punchcard to provide a cli or a helper library (like @punchcard/test semi serious 😃), but it's related to #63, I'm trying to run node debugger, but there are too many spawning processes that make breakpoints useless (node that calls cdk synth that calls ts-node). this is really useful and is akin to serverless-offline.
Another issue with debugging the generated code while on lambda is that there's only X-Ray, and you can't actually get insight of that happening inside scopes and the current call stack, having to change code to spit out console.log statements are icky.

[sam-goodwin]

I think the SAM CLI has support for running lambda functions locally and is also integrated with the CDK: https://sanderknape.com/2019/05/building-serverless-applications-aws-cdk/. Perhaps we could try that? Do you want your function to run against live AWS resources or locally mocked?

I test handlers with unit tests by passing in mocked clients for the dependencies:

const table = new DynamoDB.Table(..)
const f = new Lambda.Function(.., { depends: table.readAccess() })
const mockTableClient = ...
const result = await f.handler(event, mockTableClient);

[pocesar]

the SAM CLI looks a good starting point! I'll take a look, as I was thinking more of calling the handler from the command line or even from an adjacent file that can do the wiring on the 'synthesized' bundle. my goal was to help debugging the issues with the generated code, but might come in handy when debugging own code as well.

[sam-goodwin]

The generated code should (hopefully) be entirely transparent to the user once its mature. Is it still causing problems?

The Dependency abstraction should allow you to do a bunch of unit testing by calling Function.handle instead of running Lambda in a local container. But as previously mentioned, SAM CLI should already support that. Have you tried it?

[sam-goodwin]

Apologies that the struct-overhaul change is taking so long. Punchcard might be broken at the moment due to CDK's updates. Really wish we had a better solution for that ...

[pocesar]

no worries! we are in for the ride, it's expectedly highly iterative 👍

the issue was mainly because of that internal webpack error (#57), it wasn't a problem with the handler per-se, nor with the external code (that is testable in isolation). the handler should be slim anyway (ApiGateway.response with your response shape)

and no, it's deploying as expected, just hit the missing CORS headers nag (the APIGW one) unrelated to this.