3

So my app stack looks like this in prod:

  • Backend: AWS API Gateway + Lambda + DynamoDB + ElastiCache(redis)
  • Backend - algo: Long running process - dockerized Java app running on ECS (Fargate)
  • Frontend: Angular app, served from S3

I'd like to use https://www.cypress.io/ for end-to-end testing and I'd like to use https://circleci.com/ for my build server.

How do I go about creating an environment to allow the end-to-end tests to run?

Options:

1) Use Terraform to script the infrastructure and create/tear down a whole environment every time we run the end-to-end tests. This sounds like a huge overhead in terms of spin up time. Also the environment creation and setup being fully scripted sounds like a lot of work!

2) Create a dedicated, long lived environment that we deploy to incrementally. This sounds like it'll get messy - not ideal for a place to run tests.

3) Make it so we can run the environment locally. So perhaps use use AWS's SAM or something like this project https://github.com/gertjvr/serverless-plugin-simulate

That last option may also answer the question of the local dev environment setup however everything that mocks serverless tech locally seems to be in beta and I'm concerned that if I go down that road I might hit some issues after investing a lot of time....

Force Hero
  • 2,674
  • 3
  • 19
  • 35

4 Answers4

2

"Also the environment creation and setup being fully scripted sounds like a lot of work" - it is. its also the correct thing to do. it allows you to not only version your code but the environments that the code runs in. automating your deployment is more than just your code. i'd recommend this.

spaceman
  • 1,628
  • 1
  • 16
  • 19
  • Thanks, I'm on board with infrastructure as code. Is that still the right way to go though in terms of ephemeral environments e.g. local dev, local qa and end-to-end testing? – Force Hero Sep 20 '18 at 07:15
  • Yes, even for local-dev, qa and e2e the infrastructure as code is the way to go. Of course, for local-dev, the code will be adapted differently based on the stack differences. It will save a lot of time onboarding new developers, moving QA and E2E environments to new infra etc. – retromuz Jul 25 '22 at 23:51
2

On my side, I split my testing strategy as below:

Api: - Unit test: (use your language favorite framework) - Integration test: It depends on your InfraAsCode choice, if you use SAM or Serverless framework, you will then be able to inject event directly to your function locally. If you want to add integration part like DynamoDB or S3 interaction, you should consider using LocalStack (https://github.com/localstack/localstack) to emulate those services.

Front: - For that part, I always mock API Requests using Stub and only test front end part (I already have tested api part previously). And then you will be able to use cypress or an other framework.

Steve HOUEL
  • 197
  • 5
1

You can use the serverless framework to encode your app as infrastructure as Code and create tests

https://serverless.com
https://serverless.com/framework/docs/providers/aws/guide/testing

Banjo Obayomi
  • 1,636
  • 15
  • 17
0

How about using endly e2e and automation runner, It allows you to build testing workflow to automate build, deployment, data population and validate (NoSQL: DynamoDB, Firebase, or SQL: MySQL, BigQuery,PostgreSQL, etc), logs (cloud watch), message bus (SNS, SQS, Cloud Pus/Sub), triggering backrond or sending HTTP reques.

You can find some lambda, cloud function/ here

Or some more production project with e2e:

Adrian
  • 1,973
  • 1
  • 15
  • 28