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


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.



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.

Run your End-to-End tests using headless Chrome; Docker_Puppeteer_Jest Docker Image is announced!

About a year ago myself and @ibotpeaces sat down for a couple hours to to put together a docker images with headless Chrome that we could use for End-to-End (user acceptance) testing. At the time the tooling of both Docker and Jest where not at a place at we could get a POC (proof of concept) functional give the constants of the process being a container service, easy integration into existing projects, and using a well adopted JavaScript testing framework.

Google Chrome
Google Chrome






Fast forward to March 2018 and not only has the containerization tooling but advanced significantly but also the headless Chrome control systems. As such I sat down once gain to look into this tool chain. I am happy to announce `Docker Puppeteer Jest‘ docker image. As the name suggests running the image will spin up a headless Chrome instance, controlled by Puppeteer that triggers Jest test suites. Outputting both terminal response and image captures if so instructed.

Checkout the image on the Docker Hub or the repo on GitHub. Let me know what you think or if you find it useful. I’d love to hear from you.


Today, today is a good day.

Yesterday I sat for the AWS Certified Cloud Practitioner exam. It’s been nearly 6 months of studying, little gaming, much less beer, and far fewer trips. But as of today I am now an AWS Certified Cloud Practitioner.

While awesome, and amazing, it is tempered with the knowing this coming Saturday is the real goal. The AWS Associate Solutions Architect exam. Getting a 94 out of 100 on the Cloud Practitioner sure helps the confidence though 😀

Core software principles and design patterns.

Inspired by a recent conversation with a peer I decided to get together a list of 10 resources concerning software as a whole. Both for future reference and as a starting point for anyone else who finds it helpful. This list is agnostic of language or platform or reach. This is meant to be a intro, as no list would ever be complete with the abundance of resources available.

If you have any suggestions for a future list, message me on Twitter! Enjoy.


Inspiration for your day:

Only Thing We Have to Fear Is Fear Itself” Franklin D. Roosevelt First Inaugural Address.

That said, whatever you’re afraid of, it is not nearly as bad as you think. Get up, get dressed, and go do it.

(Within legal and ethical bounds, of course.)

If this is the new CSS, count me in.

I’ve always had a love / hate relationship with CSS. Love that it’s powerful, simply syntax, and generally human comprehensible (minus not having a ‘center this div in the middle of its parent’). Then it evolved, version 2, now version 3, SASS, pre-compilers, ugg. Can we not have a simple one focused use technology that does not get bastardized? But I digress.

During my daily reading tour my attention was brought to this article to my attention. CSS-Grid is the most amazing piece of CSS I have seen in years! Best yet most modern browsers already support it. #love

What do you think of CSS Grid and its implications for web frontend design?

Timezones and why to avoid them when programming.

During a Laravel meetup last night the issue of timezones came up; I had seen this video before but it’s still entertaining and very poignant. This is why you do not want to deal with timezones when programming.


For what it’s worth, I have been lean on UTC unix timestamp and leave the timezone adjustments to the client when displaying the date and time. It’s not perfect but it covers the majority of cases.


Also, you should subscribe to the Computerphile’s Youtube channel.

Finding the motivation to complete.

It happens to all of us. We get a awesome idea, a world changer, an industry changer even. We plan it out, using some fancy or not so fancy tech; months go by, we make good progress, we near the end; we can see the light at the end of the tunnel…then, nothing. Knowing we could do it was enough, the project never reachs release.

Over the years I personally have gotten better about completing projects I start. One of the best ways was to clearly, and strongly define what ‘done’ means. Then pick half of that to be the target ‘done’. Applying the Scotty Principle but in reverse we can work backwards and figure out how much time and effort would be needed. Gauge that against how much time and effort you’re willing to devote, then divide in 1/2. What can you accomplish in that time frame? That is your ‘done’.

Using this process I have been able to release a number of small projects. None of them were meant to be big, granted, but they got finished and I am happy with the state they are in.

How do you keep motivation to complete projects? Let me know in the comments.