Automating the automation: Dealing with dynamic objects IDs

As testers, we sometimes find that developers don’t take testing into account while writing the system and design things that are very difficult for us to test. I’ve some experiences about it that I would like to share in case they help or inspire you.

Localised ID’s

A developer on my team was once tired of redeploying many times to rename objects because of business decisions. He decided to put into place a system to store the objects so people from localisation and internationalisation could change the text themselves without need of redeployment from his side.

It sounds like a great idea, but the issue was that the id’s were also on that table, and the people that were on charge of translating the text, would also translate those ID’s without understanding what they were for.

What was before me, was a set of localised pages that “most of the times” would work.

In this case, the solution I did was to check the developer’s code to understand how he was retrieving those objects and do the same from my code.

Automatic object creation

Another case of dynamic objects Id’s that I’ve seen is when the developers would create an automatic number of items dynamically on the page. In this case, the objects were created always with id’s that didn’t really identify what object they were, but would follow an structure.

For example, if they populate a list of users based on an input, each of them could have an id on the sort of “id_1, id_2, id_3…” (at least they had id’s).

Before me, they were doing manual tests because “it was not something we could automate”.

For this case, what I did was searching for id’s in the page. Something like this:

boolean caseExit = false;

int i=0;

while (!caseExit)


if (getObject("ID_" + i++).exits)

// do something


caseExit = true;


The “do something” part could be many things. For example, we could check that all the users had a certain property.

If your “exists” throws an exception you might need a try-catch instead of if statement in here.

An important note: do this if you are not able to retrieve the objects somehow else. For example, if what you have is a table you can easily access the different rows as long as the table has an id (you don’t need ID per row). It could also be similar if this is an html list.

The problem is when you have a serie of new unrelated objects. Moreover, if this is the case for all the objects in the page (they auto populate them all somehow), maybe auto-creating the page would help better for the case (explained on my previous post).

Angular/react dynamism

With introduction of JIT (a great article explaining here: the browsers could start handling more dynamism in their websites. AngularJS (insert increasing version number here), ReactJS or VueJS are examples of frameworks that allow for this to happen.

But, as these frameworks started to get popular, some other tools were also created that would allow us to deal with this new dynamism. For example, AngularJS team created Karma, which is a NodeJS application that allows you to input your tests in the command line and aligns well with Jasmine and others tools for testing.

For end to end, you could check tools like protractor, nightwatchjs and testcafe.

There are many frameworks, extensions and customisations in the open source community. They are starting to move almost as fast as the front end tools (The frustration on front end is very nicely explained in this post: )

Each of them would be tailored for a particular case scenario, so if you are building a framework you need to do a good research first, and ask many questions to your team.

POM for dynamic objects

Many people start forgetting about page object design pattern when they start automating on dynamic objects. However I would recommend you still incorporate it as much as you can because it really helps maintaining a clean code and reducing the time to write it.

Even if you have a lot of tests, you usually don’t have the time resources to execute every single one of them. For this, you need to decide what test to run, and this could also be a difficult, repetitive and automate-able process. But that’s…well…another story.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s