Reuse protractor tests for Load Testing

Protractor tests for Angular applications, fall in the E2E (end-to-end) category.

Technically, well-written e2e tests can point at any application environment (local/staging/production) and if we run enough of them in parallel, then observing response times and server’s cpu/memory, might give some insight into early problems.

With that notion in mind, I set out to create a harness that could run multiple e2e tests.


Update July 21st 2017: An ultimate & complete solution is available: SeleniumHQ/docker-selenium

The shell script approach from a local laptop/desktop was my first attempt but I couldn’t make it work. Maybe its because I wasn’t ready to adopt the one independent test per file philosophy. I wanted to avoid changing the pre-existing e2e test’s source code.


Next I wanted to believe that someone had already solved this problem by making a generic docker container where anyone could mount their tests via a volume and run them.

An added bonus of docker would be the fact that I could run many containers in isolation. If one worked then any number of them would work as long as I had the resources. Under the rising load, when my application server would finally break then I could call the experiment a success.

Some open-source solutions exist but I found it difficult to make them work with existing company projects and I can’t say if I don’t know how to use them or if it is simply a documentation concern:

This was a slippery slope!

First thing I learned was that many E2E tests didn’t work at all so I got into the habit of splitting them up by suite and making sure they worked locally before trying to run them in a docker container.

Some screwups led to webdriver-manager blocking port 4444 and I didn’t know where its logs were. So to find the culprit and kill it, I relied on:

# find the culprit PID on mac/terminal that is using port 4444
ps -eaf | grep `lsof -t -i:4444`
# kill it (substitute PID with the actual process id you find)
kill -9 PID