Category Archives: Test automation

DRY or Don’t Repeat Yourself in test automation – part 3

My wife has a good recipe for wraps.

Imagine a situation, that I want to tweak the recipe. Last evening I ate a wonderful wrap and asked about the ingredients. At home I start to change the recipe.

What am I thinking?
“Let me see. 2 spoons of sunflower oil must be replaced by 1 spoon of sunflower oil and 1 spoon of olive oil.

I use a marker to hide the 2. Now I write 1 above the square. Writing “and 1 spoon of “. It was special kind of olive oil. I need to look this up.

First, I have to add new spices. Let me remove the old ones with my marker. The new spices are chili powder and something else.

Time to look things up on the computer.” I leave the kitchen.

Then my wife enters the kitchen to make wraps for dinner:
“What happened with my wrap recipe?”

You run a tight ship.
– Glenn Talbot

Refactoring too early

In this case I used DRY or Don’t Repeat Yourself. There is no need to have several copies of the same recipe, because the new recipe was much better than the old one. Making copies is not my favourite way to spend my time.

In this situation the improvement came too early. There was no proper recipe to make wraps for my wife.

My job is to test stuff. Refactoring is a way to clean up my code. There is a risk, that I clean up my code too early.

Groundhog Day testing

The big advantage of test automation is that the computer does the boring stuff. It can repeat steps without reducing the quality of the tests. A human being is likely to lose concentration over time.

A note for the screen reader users: characters like parentheses, dot, and braces are used in the code. It is advised to change the interpunction and symbol level before reading the code.

For my VIP Cinema app, I had written the following method to select a drink and a snack:

public ConfirmOrderPage selectColaAndPotatoChips();
{ 
  WebElement numberOfColasTextfield = 
    driver.findElement(
      By.name(NUMBER_OF_COLAS_TEXT_FIELD);
  WebElement numberOfPotatoeChipsTextfield = 
    driver.findElement(
      By.name(NUMBER_OF_POTATO_CHIPS_TEXT_FIELD);
  WebElement okButton = 
    driver.findElement(
      By.name(OK_BUTTON);
  
  numberOfColasTextfieldSnackAndDrinkPage.sendKeys("1");
  numberOfPotatoChipsfieldSnackAndDrinkPage.sendKeys("1");
  oKButtonDrinkAndSnackPage.click();
  
  return ConfirmOrderPage(driver);
}

This means:

  • order 1 Cola
  • order 1 potato chips
  • press the OK button.

Now I need a piece of code for ordering 2 Colas like:

public ConfirmOrderPage selectTwoColasAndPotatoChips();
{ 
  WebElement numberOfColasTextfield = 
    driver.findElement(
      By.name(NUMBER_OF_COLAS_TEXT_FIELD);
  WebElement numberOfPotatoeChipsTextfield = 
    driver.findElement(
      By.name(NUMBER_OF_POTATO_CHIPS_TEXT_FIELD);
  WebElement okButton = 
    driver.findElement(
      By.name(OK_BUTTON);
  
  numberOfColasTextfieldSnackAndDrinkPage.sendKeys("2");
  numberOfPotatoChipsfieldSnackAndDrinkPage.sendKeys("1");
  oKButtonDrinkAndSnackPage.click();
  
  return ConfirmOrderPage(driver);
}

This piece of code looks almost the same as the previous one. A lot of repeated lines of code, so it is time for …

Refactor 1

public ConfirmOrderPage selectTwoColasAndPotatoChips();
{ 
  driver.findElement(
    By.name(NUMBER_OF_COLAS_TEXT_FIELD).sendKeys("2");
  driver.findElement(
    By.name(NUMBER_OF_POTATO_CHIPS_TEXT_FIELD).sendKeys("1");
  driver.findElement(
    By.name(OK_BUTTON).click();
  
  return ConfirmOrderPage(driver);
}

My first step was to make the code more compact. But I still repeated the lines of code for the text fields and buttons in the method selectColaAndPotatoChips, so I should use methods instead. Small reminder to myself: DRY or Don’t Repeat Yourself.

Trust the system.
– Melissa May

Refactor 2

public ConfirmOrderPage selectTwoColasAndPotatoChips();
{ 
  selectColas("2");
  selectPotatoChips("1");
  pressOKButton();
  
  return ConfirmOrderPage(driver);
}

This code looked more readable than the previous code. But I still needed some way to change the number of Colas in a simple way.

Refactor 3

public ConfirmOrderPage selectDrinksAndSnacks(int numberOfColas);
{ 
  selectColas(numberOfColas);
  selectPotatoChips(1);
  pressOKButton();
  
  return ConfirmOrderPage(driver);
}

I introduced the parameter numberOfColas, so I could use this method for the situations to select 1 Cola or 2 Colas. One parameter fits all.

Some other small things I refactored are:

  • I changed the name of the method to selectDrinksAndSnacks. This is a more general name, so I could extend to other drinks and snacks. One name fits all? I mean all interactions with the Order Drink And Snack Page.

    We’ve got to get on the same page.
    – Phil Coulson

  • I did not like that numberOfColas was a string. This could lead to programming errors. An int or integer restricted the use of the possible values. I didn’t want to wait for a tester using the word “hundred” for ordering Colas. Or the polite Spanish tester: “Una, por favor.”. This means: one, please.
  • I also changed the method selectPotatoChips to use an integer number of Potato Chips. Consistency fits all.

To explore new combinations

A way to increase sales is to offer discounts to customers. If I have a discount code for a Cola, then I get the Cola for less money. If I take an orange juice, I have no discount. Bad luck.

I talked to the developers and hoarded some discount codes. And off I coded.

public ConfirmOrderPage selectDrinksAndSnacks(int numberOfColas, int numberOfOrangeJuices);
{ 
  selectColas(numberOfColas);
  selectOrangeJuices(numberOfOrangeJuices);
  selectPotatoChips("1");
  pressOKButton();
  
  return ConfirmOrderPage(driver);
}

This was pretty easy. I just added a parameter for Orange Juices. As time passed by, I added more parameters. Then I got a request to execute the scenarios for a regression test. This was the moment that test automation would shine.

The discount scenarios could be executed except the one which I worked on. But the other scenarios could not be used, because I added parameters like numberOfOrangeJuices. This was not the moment that test automation would shine.

This is a potential volatile situation.
– Melissa May

I used DRY or Don’t Repeat Yourself too early. What I needed, was to find the proper way to use it.

Wrongs have been committed. Now we make them right.
– Jemma Simmons

I could use git, a version control system, to restore my old code. In best case I could use the scenarios and get back to my current state of coding.

There was a big If. If the scenarios were broken in some way, then I had to repair them and merge them with the current scenarios. Making things a little more complicated than I had expected. A typical worst case.

We’ll figure it out. We always do.
– Phil Coulson

In order to keep things simple for myself I repaired the broken scenarios. I was not in the mood to use git to use an older version.

In hindsight

Let me summarise the situation of coding test automation. I was doing two things at the same time:

  1. adding new test automation code.
  2. using test automation code for a regression test.

It is like a kitchen where I am trying to improve the wraps and my wife is making new ones. The problem is, that we are using the same recipe at the same time.

It is important to know when to throw out the plan.
– Phil Coulson

In this case DRY or Don’t Repeat Yourself is not the peaceful option to choose. A simple solution is, that both my wife and I use different recipes for our purposes. The copy of the recipe is really needed for a workable situation.

I can still tweak the wrap using herbs and spices. There might be a better wrap. In the meantime my wife is baking the wraps. After all I want to have dinner with wraps.

We are solving problems we created.
– Phil Coulson

Closing note

During the weeks of programming test automation I noticed, that I had made a lot of beginner errors. These things happen. My way is to learn from my mistakes.

What you do next, matters.
– Phil Coulson

DRY or Don’t Repeat Yourself is a principle. I realised, that I should not use it without thinking. As a tester I always looked to exceptions. As a coder I had experienced the same situation.

Should I remove duplicated lines of code? Or even more important, is it smart to copy the code?

Copy that.
– Mack

DRY or Don’t Repeat Yourself – part 2

One evening I had a wrap on my plate. Then I took a modest amount of vegetarian filling. My wife noticed this:
“No wonder you can eat three wraps.”

Refactoring

My wife improved my meal with this single remark. The more filling, the better. Lucky for me, she did it, before I would eat my wrap. These small things add up.

In software development improving the code is called refactoring. The first step is to notice something wrong, which is followed by using the right solution.

Let’s go back to the wraps. My wife saw, that I did not put enough filling on my wrap. Then her solution was more filling.

Refactoring in practice

After hours of programming, I had a test scenario for the Cinema VIP app, where the number of Colas was increased because of the Desert scene in Monsters Unlimited.

Some steps from the scenario were:

  • order 1 Cola in the Drink and Snack page,
  • go to the next page,
  • regret my choice, (I did not code this, but it adds to the flavor.)
  • go back to the Drink and Snack page,
  • change the number of Colas to 2 in the Drink and Snack page, and
  • go to the next page.

Changing lines

A note for the screen reader users: characters like parentheses, dot, and braces are used in the code. It is advised to change the interpunction and symbol level before reading the code.

Then it was time for me to have a close look to the code. The line of code to find the text field with the number of Colas was used twice. First I set it to 2 and later to 1. Every time the Snack and Drink page was opened, the text field must be found again.

In my code I found the following line twice.

WebElement numberOfColasTextfieldSnackAndDrinkPage = 
  driver.findElement(
    By.name(“4958495”);

This means: find the text field with the name 4958495.

I had to change this, so I added the following line:

public static final String NUMBER_OF_COLAS_TEXT_FIELD =
  “4958495”;

This means: NUMBER_OF_COLAS_TEXT_FIELD is 4958495.

Then I changed both lines to find the text field.

WebElement numberOfColasTextfieldSnackAndDrinkPage = 
  driver.findElement(
    By.name(NUMBER_OF_COLAS_TEXT_FIELD);

This means: find the text field with the name NUMBER_OF_COLAS_TEXT_FIELD.

I had severe doubts about NUMBER_OF_COLAS_TEXT_FIELD. In my test scenario several windows were used. There was only 1 Number of Colas Text Field in the whole application. On the other hand every page had an OK button. Using OK_BUTTON is an accident to happen.

So I changed OK_BUTTON in the Drink and Snack Page to OK_BUTTON_DRINK_AND_SNACK_PAGE. So I used
NUMBER_OF_COLAS_TEXT_FIELD_DRINK_AND_SNACK_PAGE.

In this case I used refactoring to make sure, that my test automation would still work. I like code which is easy to read and change.

Time for some reflection

I noticed the recurring lines of code. This would lead to code which would be difficult to maintain. I remembered DRY or Don’t Repeat Yourself.

My solution was to use a single line of code to determine the name of the Number of Colas Text Field. If the name would change, then I had only to change this line of code.

Page Object Model

A few weeks later I had 3 scenarios with the Drink and Snack Page containing the same lines:

numberOfColasTextfieldSnackAndDrinkPage.sendKeys("1");
numberOfPotatoChipsfieldSnackAndDrinkPage.sendKeys("1");
oKButtonDrinkAndSnackPage.click();

This means:

  • order 1 Cola
  • order 1 potato chips
  • press the OK button.

These same lines of code in 3 different test scenarios did not feel quite right to me. Repeat after me: Don’t Repeat Yourself. There was still too much repetition.

I already used objects for the web elements. Then a tester introduced me to the Page Object Model. I looked at her code and saw less lines of code to do similar things.
“Why did you tell me this before?”
“First you have to get comfortable with the normal way of coding.”
She got a point.

The Page Object Model or POM makes objects for complete pages. So the Drink and Snack page was an object.

My test scenario contained the following actions:

  • select the movie in the Movie Page.
  • select the drink and snack in the Drink and Snack Page.
  • confirm the made options in the Confirm Order Page.

The first 2 steps I programmed as follows:

MoviePage moviePage = homepage.selectMovie();
DrinkAndSnackPage drinkAndSnackPage =
  moviePage.confirmMovie("Monsters Unlimited");
ConfirmOrderPage confirmOrderPage = 
  drinkAndSnackPage.selectColaAndPotatoChips();

This code was more readable than all those detailed lines of code. This also saved me a lot of space.

I put all the code for the web elements of the Drink and Snack Page in the following method:

public ConfirmOrderPage selectColaAndPotatoChips();
{ 
  WebElement numberOfColasTextfield = 
    driver.findElement(
      By.name(NUMBER_OF_COLA_TEXT_FIELD);
  WebElement numberOfPotatoChipsTextfield = 
    driver.findElement(
      By.name(NUMBER_OF_POTATO_CHIPS_TEXT_FIELD);
  WebElement okButton = 
    driver.findElement(
      By.name(OK_BUTTON);
  
  numberOfColasTextfieldSnackAndDrinkPage.sendKeys("1");
  numberOfPotatoChipsfieldSnackAndDrinkPage.sendKeys("1");
  oKButtonDrinkAndSnackPage.click();
  
  return ConfirmOrderPage(driver);
}

In the meantime I could not resist another refactoring. I put all the code for the Snack and Drink Page in one Java file. So all mentioned web elements in this file are on this page. So I renamed NUMBER_OF_COLAS_TEXT_FIELD_DRINK_AND_SNACK_PAGE to
NUMBER_OF_COLA_TEXT_FIELD.

Cliffhanger coming up

At the end I used DRY or Don’t Repeat Yourself. Less copied lines meant less problems. It was time to hit the wall again.

To be continued.

DRY or Don’t Repeat Yourself in test automation – part 1

This month my wife thought that it would be a great idea to make wraps. She looked on the internet and found a good recipe.

The case of 3 recipes

Do you have a copy for me?

Suppose one of my kids would like to make wraps at a friend’s place. The kid copies the recipe for the wrap and the vegetarian wrap filling. Some weeks later I have to make wraps with minced meat filling. So I copy the recipe for the wrap and the wrap filling.

At that moment there are 3 recipes in use. There is no problem, because the wraps are still tasty.

Any updates?

Now imagine the following situation.
One evening I get a call from one of my kids.
“What is the bottle in the third row and second column?”
I open the drawer and pick the bottle.
“It is the sunflower oil.”
“Thanks, dad. Now I can continue with the wraps.”
“Wait, did I not use the right one?”
“Mom told my friend and she wrote down the change.”
“Then you already know, that mom adds an extra spoon of oil.”
“Wait. What did you say, dad?”

Don’t Repeat Yourself

The more copies you make, the more things you have to watch. Especially, if things change. Now I could assign a task to myself to update all the 3 recipes all the time. That sounds to me as a part time job. I would rather spend that time on cooking.

In software development DRY or Don’t Repeat Yourself is used to avoid these kinds of mistakes. The more code I copy, the more I need to update in case of a change. This is part of my job. It would be great, if I could reduce these changes to a minimum.

Change the right field

In the following story the companies and products have been obfuscated.

After a few weeks of coding, I had test automation in place for the VIP Cinema App. In most scenarios the order page for the drink and snack was used.

In one test scenario I would order a drink and snack and go to the next page. Then I would go one page back and change my order. The desert scene in Monsters Unlimited is so good, that people get thirsty. I definitely needed 2 drinks.

A note for the screen reader users: parentheses, at symbol, dot, and double quote are used in the code. It is advised to change the interpunction and symbol level before reading the code.

Don’t Repeat Yourself or DRY in practice

Now I had several lines in my code to change the number of Colas on the drink and snack page. The first line of Java code looked like

WebElement NumberOfColasTextfieldSnackAndDrinkPage = 
  driver.findElement(
    By.name(“4958495”);

This means: find the text field with the name 4958495.

The second line of Java code was:

NumberOfColasTextfieldSnackAndDrinkPage.sendKeys("1");

This means: enter “1” in the Number of Colas in the text field on the Snack and Drink Page.

The third line of Java code was:

NumberOfColasTextfieldSnackAndDrinkPage.sendKeys("2");

This means: enter “2” in the Number of Colas in the text field on the Snack and Drink Page.

DRY in more details

For my code I used Java. This is an object-oriented programming language. The Number of Colas text field in the Snack and Drink Page is an object, which I used for test automation.

A test scenario would only contain the following code once:

WebElement NumberOfColasTextfieldSnackAndDrinkPage = 
  driver.findElement(By.name(“4958495”);

The code to make this text field was written once instead of twice. I did not repeat myself. In this particular DRY or Don’t Repeat Yourself was not applicable.

Ready for the change

For me and other people 4958495 is not related to a Number of Colas text field. It makes the code hard to read.

I assumed, that the development environment had assigned a random number to each web element. Luckily it was a unique number, so my text automation code would work at that moment.

If a developer would change something in the Snack and Drink Page, then the random number or change might also change. this would result in broken test automation code. That is the bad part of my job.

The best way to identify the text field was to use id. id is short for identity. id is an attribute of the web element, which is used to identify it.

I talked to another tester, who agreed with me. The programmer should change the code for the text field. In turn I would have to change my test automation code:

WebElement NumberOfColasTextfieldSnackAndDrinkPage =
 driver.findElement(By.xpath(contains(@id, “NumberOfColasTextField”));

If the name would change to some other random number, the id would be the same.

A cliffhanger at your request

The code with the name attribute looked good enough for me, but there was still too much repetition.

To be continued.