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.
Joe Colantonio is the founder of TestGuild, an industry-leading platform for automation testing and software testing tools. With over 25 years of hands-on experience, he has worked with top enterprise companies, helped develop early test automation tools and frameworks, and runs the largest online automation testing conference, Automation Guild.
Joe is also the author of Automation Awesomeness: 260 Actionable Affirmations To Improve Your QA & Automation Testing Skills and the host of the TestGuild podcast, which he has released weekly since 2014, making it the longest-running podcast dedicated to automation testing. Over the years, he has interviewed top thought leaders in DevOps, AI-driven test automation, and software quality, shaping the conversation in the industry.
With a reach of over 400,000 across his YouTube channel, LinkedIn, email list, and other social channels, Joe’s insights impact thousands of testers and engineers worldwide.
He has worked with some of the top companies in software testing and automation, including Tricentis, Keysight, Applitools, and BrowserStack, as sponsors and partners, helping them connect with the right audience in the automation testing space.
Follow him on LinkedIn or check out more at TestGuild.com.
Related Posts
Look, I’ve been doing test automation for over 25 years. I’ve heard the predictions. “Manual testing is dead.” “AI will […]
The 72.8% Paradox That Changes Everything After interviewing 50+ testing experts in 2025 and analyzing data from our 40,000+ member […]
Look, I’ve been doing this testing thing for over 25 years now. I first wrote about the AI “three waves” […]
What’s New in Low-Code/No-Code Testing for 2026 A lot had changed on the The low-code/no-code testing space and it has […]