This is my use case now:
API Gateway - Lambda - SES/S3
I wrote my unit tests. Cool
I wrote a component test that tests my handler function as a whole, sinon.stubbing my aws-sdk function calls (s3.getObject and ses.sendEmail). I did it with proxyquire, Following this example. That’s nice.
I wrote an integration test with serverless-mocha-plugin / lambdaWrapper that tests the whole handler function together with the aws services, getting a test bucket from s3 and sending email to success@simulator.amazonses.com. Both test bucket and sender email are configurable from env vars in serverless.yml
I rewrote the above test, but now using docker-lambda. It felt good to know that I’m now testing in a very similar environment to production, but I didn’t like the fact that docker-lambda doesn’t read from serverless.yml, so I had to pass my environment variables in config:
const config = {
dockerImage: 'lambci/lambda:nodejs6.10',
handler: 'handler.myFunction',
dockerArgs: ['--env-file', 'envVarsForDocker']
}
I’ll probably write now an end-to-end test as @nerdguru explained here so I can test from API Gateway forward, but implementing different stages (dev/prod) through serverless.yml so I can read from test bucket and send email to test email.
Obviously keeping all that is a huge overkill and hard to maintain. I think I’ll keep only my unit tests, component tests and my end-to-end tests. What do you think?
Other questions:
- is there a way I can use dockerLambda integrated with serverless framework, so it takes all appropriate action described in serverless.yml?
- Should I really test from API Gateway forward since I’m using the default lambda proxy integration from serverless?
- What other test can be added or replace one of those mentioned?
ps. This is for learning purposes so don’t get attached to my use case. S3 could be any database. in case of dockerLambda, suppose we add a npm package that needs to be natively compiled.