I was recently asked how automated tests should be named to reflect they were built using Test Studio. My response, hopefully not too blunt, was “Don’t.”

Good naming conventions in software are critical. Code is read, re-read, re-re-read, and re-re-re-read 5,632 times more than it’s edited¹.

Readability is critical to maintaining and understanding our software. With that in mind, great names for classes, methods, variables, and tests are crucial! We need to ensure we’re able to quickly discern what the system’s behavior is, or what a particular test is covering.

Good names are about intent, not implementation. You should be using names to clarify why something is happening, not how.

Naming styles, patterns, and toolsets evolve over time, and that’s not a bad thing. Back in college when I was learning COBOL I remember having to preface all my modules with numbers so things would run in the proper order. I ended up with source code that looked pretty awful. JUnit, one of the grandfathers of testing frameworks, previously forced its users to begin methods with “Test” and classes with “TestFixture” in order to run properly.

Good Names Abstract Out Implementation

Let’s dive down from tools and platforms to actual source code. Abstraction gives us the ability to hide implementation from consumers of an API, class, or method. This is awesome because I can make a sensible method name that describes the intent of what I want to do without exposing the gory details. This is particularly important when we’re using tests as modules within other tests.

In the figure below we’re using a test that handles cleaning up test users from the database. Note the test’s name says nothing about whether the cleanup is done via a command-line utility, web service end point, or a direct call to a stored procedure in the database.

I can change the implementation in that test and no other test that uses it will care. (Nor should they.)

Good Names Help Us Understand What’s Going On

Rising back up to the meta level, clear names help us understand what we’re testing. The figure below shows a dynamic test that checks our Basic Validation Tests (BVTs). Each test in the list is explicit in what it’s testing, not how it’s doing its job.

Good Names Remind Us What We Were Thinking Months Ago. Hopefully.

Perhaps the most important reason for good naming goes back to readability. It really is the most important part of software engineering/development/craftsmanship. I’d say it even trumps correctness.

How many times have you gone back to code or tests you wrote a year ago and can’t quickly decipher what it is you were trying to do? Heck, I sometimes get lost in code I wrote last week! Good naming conventions help minimize the time needed to shine the light on what you or one of your colleagues (or worse yet, some contractor that’s no longer with your company!) were thinking when they wrote the piece some time ago.

Naming Evolves. Don’t Fear The Change.

Naming styles change over time. I don’t name my tests the same way I did a year ago, much less ten. Regardless, focusing on clarity of a test’s intent is critical. Don’t get lost in the weeds of how the test is doing its job.

How have your naming conventions evolved over time?

[1] This statistic is completely fabricated. Obviously. But there’s plenty of evidence that code is read many, MANY more times than it’s edited.

About the author

Jim Holmes

Jim Holmes has around 25 years IT experience. He's a blogger and is the Director of Engineering for Telerik’s Test Studio, an awesome set of tools to help teams deliver better software. He is co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. Find him as @aJimHolmes on Twitter.

Interested in chatting with Jim at a conference? Check out his speaking schedule!