Automation Testing

Test Automation Code is Real Code

By Test Guild
  • Share:
Join the Guild for FREE

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

CoryCleanCode

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?

TestTalks

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.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. Thanks, Joe, for talking about clean code! I’m always evangelizing for people to take seriously the code they write for test automation. While working as an automation consultant for a company that outsources a few of their automation projects, I continue to be amazed by the code that is delivered by some of these “professionals”. I hope that clean code is more prevalent in proper software development, but perhaps I’m naĆÆve.

    For those interested in clean code, I highly recommend the book “Code Complete: A Practical Handbook of Software Construction, Second Edition” by Steve McConnell. That book was the inspiration for many of the static code analysis features we added to our Test Design Studio product.

    1. Hi Boyd! One of the points Cory House make in the training, as a key principle of clean code, is having the right tools. If a test engineer is creating QTP/UFT automation then I think Test Design Studio is one of those “right” tool that helps facilitate clean code. I reviewed Test Design Studio a few years ago and I’m sure its even better today.

      Also in my TestTalks interview with Cory House he also recommends Code Complete – I guess great minds really do think alike :)

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Bridging the Gap Between Manual and Automated Testing

Posted on 03/13/2024

There are some testers who say thereā€™s no such thing as manual and ...

Traffic Driven Testing For Realistic Kubernetes Testing

Posted on 03/05/2024

First before we get into it you might be asking — what is ...

5 Key Reasons to Choose Private Cloud for Mobile App Testing

Posted on 02/16/2024

Remote work has fixed a lot, but it's made testing mobile apps a ...