Testing Internal Processing

Testing Internal Processing

These are internal-ish testing notes.

Testing controller and jobs processing without node shim.

jets process:controller '{"pathParameters":{}}' '{"context":"data"}' "handlers/controllers/posts_controller.index"

jets process:job '{"we":"love", "using":"Lambda"}' '{"context":"data"}' "handlers/jobs/hard_job.dig"

Testing the generated node shim handler and the controller processing.

cd spec/fixtures/apps/demo
jets build # generates the handlers
cd /tmp/jets/demo/app_root
node handlers/controllers/posts.js

API Gateway

Jets automatically uses the Lambda Proxy Integration to connect to API Gateway. So the controller methods expect the Lambda Proxy Integration payload structure.

You might be surprised if you are trying to pass parameters to your controller. An example explains best:

jets process:controller '{"id":"tung"}' '{}' "handlers/controllers/posts_controller.show"

Jets controllers you to wrap up the event payload in the Lambda Proxy Integration structure. This is what you were probably intending:

jets process:controller '{"pathParameters":{"id":"tung"}}' '{}' handlers/controllers/posts_controller.show

Note: {"pathParameters":{"id":"tung"}} vs {"id":"tung"}.

jets process is an internal tool if you want to test the ruby command that the node-shim shells out to. The better and recommended command if you want to test your controllers with the CLI is the jets call command. Here's a quick example:

jets call posts-controller-index '{"id":"tung"}' --local

The jets call commands detect when you are calling controllers and will transform the payload to a Lambda Proxy Integration payload for you. For more examples and help:

jets call help