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.
Top comments (0)