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
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