Clean(er) Test Automation Code

This blog post tries to explain why it is important to really care about your test (automation) code and write clean (automation) code. I’m mainly involved in test automation, so some of the examples given are related to that, but most are related to programming in general. Often test automation code is less exposed to a formal review process. Keep in mind; test automation is code and should threated like that.

I hope this blog post will bring you one step closer to clean(er) code.

Test Class Naming
Defining a classname for unit testing is rather easy; it’s the same name as the implementation class. In terms of functional or integration testing, the classname should reflect the feature or functionality you are testing.

For example:

public class LoginTest { }

public class RegistrationTest { }

public class OrderTest { }

Test Method Naming
I have been on many projects, some Greenfield* others continuing development on an existing codebase. Every project has its own naming convention* or not ☺. The following can happen in projects without naming convention:

@Test
public void test1() { }

@Test
public void test2() { }

// or:

@Test
public void testLogin() { }

Do you get the point? It’s all very descriptive, isn’t it?

Imagine you have to share this with a colleague or you have to present the results to non-tech colleagues, they have no clue what’s going on.

I very much like the naming convention introduced by Roy Osherove (http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html). The basic idea to describe the tested method, expected input or state and the expected behavior as the name of the test method.

public void nonExistingCredentialsGiven_ShouldThrowException() {

}

We can adopt this principle for feature testing as well.

public void nonExistingCredentialsGiven_ShouldShowErrorMessage() {

}

By following this naming convention we can make sure that the intent of the test is clear to everyone. (Off course the implementation should reflect the method name) Method names are a bit longer, but self-explanatory.

Naming of fields and local variables

Another thing that strikes me is the use of non-explicit fields or variable name. Like:

i for loops
page when applying the Page Object Model (everything is a page lol)
And so on..

We need to be more explicit if we want to create readable code.

Magic numbers
Magic numbers indicate the direct use of a number in your code. By doing this, your code becomes less readable and harder to maintain.

Example implementing magic numbers:

public class Username {

	private String setUsername;

	public void setUsername(final String username) {
		if (username.length() > 10) {
			throw new IllegalArgumentException("username");
		}
		this.setUsername = username;
	}

}

After refactoring

public class Username {

	private static final int MAX_USERNAME_SIZE = 10;
	private String setUsername;

	public void setUsername(final String username) {
		if (username.length() > MAX_USERNAME_SIZE) {
			throw new IllegalArgumentException("username");
		}
		this.setUsername = username;
	}

}

The refactored example allows you to easily update the maximum size of a username, even if it’s used in different methods.

A general rule of thumb might be when applying any naming convention is to be very explicit.

Greenfield: setup a project from scratch.
Naming convention: set of rules

Other Test Naming Conventions: https://dzone.com/articles/7-popular-unit-test-naming

Share This: