How Complicated Should Automation Test Code Be?

Imagine the scene: you are working as the tester/QA in a T-shaped agile team. When you write your automated tests, you need approvals to merge your PR.

There is normally one or more developers who want to help optimise your code. Making it as efficient as possible is a good thing, right?

Well, that depends on quite a few factors.

• Who is contributing to the tests?

• Who needs to read them?

• How familiar is everyone with the language/framework being used?

In a T-shaped team, people should and will be exposed to the work everyone else is doing. Will everyone be able to read the code? Here is an example in JavaScript, using FizzBuzz (from code.golf - a great site for getting better at coding):

for (var i = 1; i < 101; i++) {
     if (i % 15 == 0) {
	 	console.log("FizzBuzz");
	} else if (i % 3 == 0) {
		console.log("Fizz");
	} else if (i % 5 == 0) {
		console.log("Buzz");
	} else {
		console.log(i);
	}
 }

This is the simple version of the solution. Someone new to code would need to know what a for-next loop, if, and the % operator all do.

Now for the more efficient version of the solution:

for (let i = 0; i < 100;) console.log((++i % 3 ? '' : 'Fizz') + (i % 5 ? '' : 'Buzz') || i)

Here, we have a couple of ternary operators, which I didn't get taught at school! Is this more efficient code? Without a shadow of a doubt. Is it easier for someone who doesn't know code to read? That would be a big no.

The same goes for using more "old-school" ways of writing automation, not just code. Which of these is easier for someone to read?

page.locator('//*[@id="root"]/div[3]/div/div/div/div[4]/div/form/div[1]/div[2]/div/div[2]/button').click()

Or :

page.getByText('Save').click();

Put yourself in the shoes of the poor BA or Product Owner on your team who is trying to help review a PR to ensure the tests do what they are supposed to. Or even the new QA who is just starting to learn automation.

You could be in a situation where everyone knows the languages you are using, and if so, Kudos! Otherwise, before you make that refactor, think about who else could help make your tests better and whether the additional efficiency will help them.