Open martin1yness opened 8 years ago
Going off of the tests in the project itself (see: test/integ/lambda_invoke_test.js), lambda_invoke can be used in integration tests by spawning a grunt subprocess to run the desired target, then assert that console output matches some expectation.
Shouldn't be terribly difficult to add an "expected_response" option though.
What use case did you have in mind?
For a unit test it seems simpler to just call the functions you want to test directly from a testing framework of your choice.
For an integration test I think you'd want to actually upload it to Lambda and run it seeing as there's no guarantees that this grunt plugin will replicate the Lambda environment accurately.
I primarily see lambda_invoke
as a fairly crude helper for manual testing during development, although I'd be interested to know if there are reasons to use this for automated testing which I hadn't considered.
I think it would be beneficial to use lambda_invoke to verify that packaging succeeded. My initial thought was, "while we're at it, let's just use the multitask itself to define and run an integration suite." But since a returned error always counts as a task failure, I thought it may be helpful to explicitly state when such errors are expected (hence my embarrassingly messy pull request). Then, only results that are not expected cause grunt to exit, which could be directly used in a CI setup. Asserting on output takes that a step further and ends up saving a fair amount of boilerplate to achieve something very similar to the integration tests you have in the project proper.
Provides a function to invoke lambda with a event.json, but doesn't provide a facility to verify the response from the function. What is the purpose of this
lambda_invoke
without verification?