Test Automation Code is Real Code

Is Test Automation real Development?

As test engineers, how often have we proclaimed that test automation code is real code– and should be treated like any other development project?

I say it all the time.

Since test automation code is development code, it should adhere to the same standards –code reviews and the like–just like any other development effort.

For example, I’m currently an automation/BDD lead for a large company. I created an automation framework that all the scrum teams use for Java/Selenium/Behavior Driven Development. Because of this, I’m involved in all code reviews of BDD test automation and have to decide if the code can be promoted to our production CI environment.

This has been a daunting task, but one thing that has helped me tremendously is a PluralSight course by Cory House called Clean Code: Writing Code for Humans.

Pluralsight course Clean Code: Writing Code for Humans

In his three hour course, Cory covers all the key concepts you need to know to create clean, readable code. The course is timeless, because the principles Cory shares apply to code written ten years ago, and will most likely apply to code written ten years from now.

The course is geared towards development code, but the same principles apply to creating test automation code written in any of the Selenium language bindings, such as C# and Java. Following are some key takeaways from the training that I now apply to all my test automation code reviews.

Make test code readable for humans

First, you should be creating your code with the reader of the code in mind — not the computer. Keeping this in mind as you program forces you to ensure that the names you assign to variables and classes are aptly named, which will make it easy for others to know what your code is doing.

For instance — during a recent code review, I noticed some variables named startR and endR. I had no idea what they were referring to. After some digging, it turned out that some teams were using startR as an abbreviation for startRow. Really!? Why would you name a variable startR just to save two characters? To make matters worse, another team was using the same variable name startR to mean startRequest—WTH?! ?

The moral of this example is: don’t use abbreviations. Put a little extra effort into creating nice, readable names for all your variables, classes and methods. Those names can be as long as is necessary to make it readable — just like a sentence in a book.

As Cory mentions in his section on naming matters “Naming selection has a huge impact on the readability of our code. Remember — understanding the programmer’s intent is the biggest problem, so we should strive to be crystal clear about what we meant to do.”

Creating well-named variables, methods and classes not only makes your test code more readable, but will make it easier to maintain over time.

DRY – Don’t Repeat Yourself Test Code

Another clean code principle that is covered is DRY (Don’t Repeat Yourself). The DRY principle basically means that each piece of logic should be coded once and only once. Duplicate code makes the code harder to maintain; the less code you write the better, since more code to maintain means the greater chance you have for bugs to creep into your test framework. This is not only a basic, clean code must- follow, best practice — but code duplication is a big pet peeve of mine.

I’ll be honest – I’m lazy — and because of this I hate having to repeat myself. To me, seeing someone take the same chunk of code and copy and paste it everywhere is like someone dragging their fingernails across a chalkboard. For example, in one code review someone had a class that contained at least 25 instances of the same block of code, copied and pasted in multiple methods. To me the lazy (and correct) thing to do would be to create a method that contains the code once, and then reuses the method as often as is needed. Then, if anything changes you only need to make the change once in the method.

There are many more principles/best practices that Cory covers in the course, including:

• Naming
• Conditionals
• Functions
• Classes
• Comments
• How to stay clean
• When to refactor

So if you want to have clean test code that is developed using development best practices, this course will be well worth your time. I have no affiliation with Pluralsight, nor any monetary gain for this endorsement. I just feel strongly that this course and (many of their others) are well worth the $29 monthly fee.

Want to hear more?

Check out my TestTalks Episode 13, where Cory speaks in detail about clean code principles and how to apply them to your test automation efforts.