Docker-Selenium Video Recorder

Cesar Augusto Rayo Zapata — Fri, 20 Jan 2023 22:07:09 +0000

This post is intended for all those who use docker-selenium.

Since I started using "dockerized" Selenium grid, I was always curious about the possibility of recording the actions we perform within a browser container (chrome, edge, firefox) and when I saw there was a solution in place for it, I just jumped into it, it was basically by using selenium/video:ffmpeg-XXXX Docker image; starting and stoping containers manually, but it was quite too raw, mainly because of the fact we need to kill the container in order to get the video file.

So I tried to create a logic layer whose main task was going to be handle this situation; avoid start/stop containers every time. As the thing got more complex and wanted to get more control, I ended up creating a service that can be deployed either using docker-compose or Helm Chart.

The service is intended to be exposed in the port 5001 of the machine where Selenium Grid is running, and it will look something similar to this:

Start recording the screen of a given node:

$ curl -X POST http://localhost:5001/start -H "Content-Type: application/json" -d '{"videoName":"my_video","targetDisplay":"chrome-display"}'
{"file": "my_video.mp4", "status": "recording"}

Stop recoding

$ curl -v -X POST http://localhost:5001/stop
{"file": "my_video.mp4", "status": "stopped"}

The file will be saved on the path you have specified in the deployment (keep reading for more details)

It's obviously the first steps for having a robust service that can take advantage of the replicas we might have in the Helm Chart or the Compose deployment, but this is a solution that worked for me and hope it does for you!

All that intro just for sharing this with you Selenium Grid + Video Recorder, Happy testing!!

Step Functions as Test Automation Framework?

Cesar Augusto Rayo Zapata — Mon, 21 Feb 2022 16:58:57 +0000

Have you ever faced any issue with your infrastructure when running Test Automation scripts? Have you wondered if there is an easy way to find where the test is broken? perhaps a kind of graph where it tells you where the test got broken?.

Probably this is not your case, or maybe you already are using a good framework that solves all these issues, but what I want to share with you is an idea that we were able to put in place some years ago.

For starters, we will have to understand what a test case really is:

A test case is just a bunch of actions that we have to perform in a given order to finally get a predictable result, which in most of the cases we ended up creating a script so we can run it whenever we want and even make it part of a CI/CD solution.

But how is this related to AWS and Step Functions? what's the benefit we saw there? so if we take a look to what actually the Cloud Computing solves, or what actually Serverless mean, it goes to the simple fact that you don't have to worry about the infrastructure.. meaning you don't deal with OS updates, plugins, or even security gabs.. and guess what.. that was exactly what we were looking for.

So if we go to the definition of a Step Function, and we think of it as a States Machines, that's exactly what a test case is a group of steps that we perform in a given order". All we have to know is that there will be a "context" that needs to be share between states.

Imagine using Selenium, Python, AWS Step Function and AWS Lambas to create this solution.

We faced several issues there, but the biggest one, taking in account we used lambdas as the mechanism in each state to execute a piece of code that uses Selenium web driver, was to share the driver between states.

How to solve this? one of our best options; use a place where we can store this "driver" so the next state will know what to do, we decided to use AWS Dynamo DB, meaning somehow we will have to convert and store the driver there.

Back in those days we were using python as the main PL that was executed in the lambdas functions, and TBH there were a lot of options to "convert" the driver object to a format Dynamo DB could understand.

Having the serialized object, it was a matter to use Boto3 and a couple of IAM roles to be able to write/read from Dynamo, so it became the pre and post steps we executed in each state.

We ended with a test case that looked much as any state machine, so if a state failed for any reason (a lambda) we could see that in a nice graph and for details we always could take a look to the AWS CloudWatch logs.

DEV Community: Cesar Augusto Rayo Zapata

Docker-Selenium Video Recorder

Start recording the screen of a given node:

Stop recoding

Step Functions as Test Automation Framework?