AWS Lambda internals

Ran and Nitzan over at epsagon did a two part article on Medium about  AWS Lambda and its internals / runtime environment. It is a pretty interesting read if you are into the serverless architecture specifically or Lambda in general.

The cost of scaling up.

In my time s working in the software realm I have worked on projects of various sizes. Local bands wanting a web presence, user generated content upload sites, college assignments, financial industry video services, national health care web applications, on board ship systems, social media aggregation, US domestic distributor for foreign sourced video content, and currently a software security and end user system monitoring service. Some projects were small, some large, some simple, some complex.

Start ups are well known and sometimes even idolized for their ability to take an idea from concept to production in a very short about of time. In the world of business having a small time to market can mean the difference between success and ruin.

Larger organizations are often scoffed and or even shrugged off due to the exact opposite. However, the larger organizations typically have systems that a dozen startups would get lost inside of. Many times these system have had a dozen or more teams operate and iterate on the system. Knowledge applied, knowledge lost, knowledge incorrectly documented. But at the end of the day bringing the business revenue. Money talks, bulls*** walks.

These two different types of entities have different constraints, different pressures, and different driving factors.  Not every org. can be, nor want to be, Google, or Twitter, or Instagram. Then again, not everyone wants to be the DoD, Wells Fargo, or General Electric.

Tutorial: Using Docker_Puppeteer_Jest to execute a headless Chrome End-to-End (user/acceptance) testing suites.

The problem:

We know that unit testing is an essential part of software engineering (at least we should all know that). Integration testing assure us that all the pieces work well together properly. At the very top of the pyramid is end-to-end (sometimes called user or acceptance) testing. This is the test set that loads the application, clicks buttons, submits data, reads data. In general, it acts like a user and assures us the applications works in the eyes of the user as it is intended to. Unfortunately in order to emulate the user experience archaic and many time s complicated system were used. These system were expensive to setup, costly to maintain, and fragile to run.

Herein I will show you in less than 6 steps how to use Chrome to emulate a user visiting a number of social media services and provide visual feedback as to what was rendered in the browser.

Pre-flight requirements:

Basic CLI / Terminal abilities

Docker

How to do it:

1) Download the image from Docker Hub via the CLI: docker pull davidjeddy/docker_puppeteer_jest

2) Clone the source repository so we can use the example test suites: git clone git@github.com:davidjeddy/docker_puppeteer_jest.git

3) Now lets change into newly created directory: `cd docker_puppeteer_jest`

4) Finally we execute the image: docker run -t -v $(pwd):/app --name dpr --rm davidjeddy/docker_puppeteer_jest. In this example we are mounting the code repository into the container at the /app directory location.

5) If all went well we should see the following in the terminal:

Congratulations, you have just executed your first user acceptance test suite using headless Chrome in a container.

To make it even easier, lets make an alias the execute the custom docker run command. Something like alias 'dta'='docker run -t -v $(pwd):/app --name dpr --rm davidjeddy/docker_puppeteer_jest'. Now type dta and press enter.

Next Steps:

To map your project into the container replace -v $(pwd):/app in the docker run command with -v {Your projects absolute path here}:/app.

Under the hood:

Docker starts a container with Chrome as the browser, Puppeteer starts a headless Chrome session. All of this isolated from the host machine as is the nature of containers. The Jest testing framework is then triggered and the test suites are auto-detected due to there directory location and naming scheme. Jest then executes the tests providing output and screen capture images to ./tests/_ouput/ which is volume mounted to the host machine.

 

Conclusion:

This process can be used with a number of frontend architectures. React, Vue, jQuery, static content, DOM manipulation, and any other material rendered a client browser. The world, as it is said, is your oyster.

I hope you enjoy your acceptance testing using a headless browser and all the assurances that come with it. Hopefully you found this useful to increasie assurance that you changes get to production without negatively affecting the quality of your projects.